On Wed, Jan 13, 2010 at 9:28 PM, Peter Kasting <[email protected]> wrote: > On Wed, Jan 13, 2010 at 11:22 AM, Craig Schlenter > <[email protected]> wrote: >> >> Other than the immediate gain of "hiding" crbug.com/28749, > > Which you have a patch (actually two, but one with r+) for, right?
True. I was tweaking the latest patch though and was still hoping to get some feedback on it (thanks for the alignment comments btw.). >> I think the biggest >> benefit is that end users relying on 4.4 builds are likely to have a more >> stable >> experience in future since it is a safe default. > > I don't understand what you mean. Whichever way we set the flag, we'll be > compiling with it. So that will be the "safe" thing for others to compile > us with. Throwing -fstrict-aliasing has the added advantage that it makes > _both_ settings "safe". It does however make the default compile "unsafe" for the case where the compiler doesn't throw a warning as is the case for issue 28749. >> The other thing it buys us is a more relaxed timetable to solve the >> aliasing >> problems if it doesn't break the tree by default. > > Do we have other aliasing problems? If so my opinion changes. There are some aliasing issues still in play. Off the top of my head: 1. unit_tests has what might be an issue in stl_tree.h or a compiler issue (bug filed with gcc ppl) and it was already using -fno-strict-aliasing to avoid this with gcc 4.4. 2. skia has an unresolved issue. Note the filing date: http://code.google.com/p/skia/issues/detail?id=18 3. v8 has an aliasing issue in dtoa and somewhere else that I forget. 4. there are issues in third party code of course eg. icu, webkit etc. --Craig
-- Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
