// ui::CompositionUnderline should be identical to // WebKit::WebCompositionUnderline, so that we can do reinterpret_cast safely. COMPILE_ASSERT(sizeof(ui::CompositionUnderline) == sizeof(WebKit::WebCompositionUnderline), ui_CompositionUnderline__WebKit_WebCompositionUnderline_diff); // TODO(suzhe): convert both renderer_host and renderer to use // ui::CompositionText. const std::vector<WebKit::WebCompositionUnderline>& underlines = reinterpret_cast<const std::vector<WebKit::WebCompositionUnderline>&>( composition.underlines);
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
--
+1 to enabling aliasing support. doing it on a repo by repo basis would probably be saner (restrict it to places where we build with -Werror).
I recently found out the hard way that webrtc requires unstrict aliasing. If you take the approach in your CL then webrtc will break (at the very least have video corruption (263657)) because today it builds with chromium_code=1. That particular case is fixable by suppressing strict-aliasing in the webrtc gyp forest (or fixing the aliasing violations!) but I just thought I'd point out this example in case there are other third_party-flavored codebases that are in the same boat.(I am in favor of strict-aliasing in general, FWIW)
I'm leaning more and more towards just using -fno-strict-aliasing, and enabling corresponding warnings if possible (i.e. warn about detected violations of strict aliasing to flag suspicious code, but do not change how code generation / optimization works).
Usually, if your code cannot compile correctly with strict aliasing on, you have some scary code that may not be buggy now, but can easily lead to bugs later. "Strict aliasing OK" is something of a code sanity check that the code doesn't do as many questionable pointer transforms and the like. (Admittedly, it's often possible to "fix" strict aliasing problems by replacing one bit of questionable logic with another, so it's not a guarantee.)The performance angle is hard to predict. Strict aliasing can buy performance when it enables more aggressive loop transforms. Otherwise it may not gain performance. But I don't see performance as the primary reason to enable the flag.
reason to risk the bugs.If Mozilla didn't find any performance improvement, I don't see a good
P.S. What's the word for "optimize some code into a behavior the
author didn't expect because the author wrote incorrect code"? ;)
--