[ https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978347#comment-13978347 ]
James Peach commented on TS-302: -------------------------------- I moved this out of "Patch Available", since the attached patches do not address the issue of the codebase being strict aliasing safe. > -fstrict-aliasing optimizer generates bad code > ---------------------------------------------- > > Key: TS-302 > URL: https://issues.apache.org/jira/browse/TS-302 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup > Reporter: Miles Libbey > Assignee: Phil Sorber > Priority: Minor > Fix For: sometime > > Attachments: no-no-fstrict-alias.patch, ts-302.patch > > > (moving from yahoo bug 525119) > Original description > by Leif Hedstrom 4 years ago at 2005-12-16 08:41 > Not sure if this is a compiler bug or a code issue on our side, but enabling > the > -fstrict-aliasing optimization option generates faulty code. This optimization > technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm > explicitly > turning it off with > -O3 -fno-strict-aliasing > This solves the problem where the traffic server would return data of 0 or 1 > length out of the cache. This initially looked like the cache corruption > problem, but is completely different and unrelated. The cache corruption > problem > has been fixed and closed. > I'm opening this bug as a reminder, at some point we should isolate which code > triggers the strict-aliasing problem, and confirm if it's a compiler bug or a > problem in our code. > > > Comment 1 > by Michael Bigby 4 years ago at 2005-12-16 09:07:40 > I'm recommending that we get Ed's input on this. He may some insight compiler > issues... > > > Comment 2 > by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07 > That'd be great! > We haven't had a chance yet to review the code that might be affecting this, > it's obviously something with unions and how the compiler handles > storage/alignment on the members. > > > Comment 3 > by Ed Hall 4 years ago at 2006-03-03 11:46:52 > This is with gcc 2.95.3, correct? There have been a number of complaints > around > the 'net about problems with -fstrict-aliasing. I've not really looked very > deeply into it, though I should mention that certain C code was known at the > time to malfunction when by-the-standard aliasing rules were enforced > (starting > with the Linux kernel). > In essense, the -fstrict-aliasing optimizations assume that any particular > part > of memory accessed via a specific type of pointer won't be accessed as another > type. There are a set of optimizations that are safe only when it can be > guaranteed that a given bit of memory hasn't been manipulated via pointer; if > the compiler assumes that the rather arcane C aliasing rules have been > followed > ("aliasing" in this case meaning accessing a given bit of memory with more > than > one type of pointer), there are more situations where such optimizations can > be > applied. Code which uses type casts where unions might be more appropriate is > the most likely to break aliasing rules. > In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying > the > C aliasing rules, and has added warnings for obvious violations. It's never > been clear to me if gcc 2.95.3 was actually broken or not, or if there simply > was a lot of code out there that ran afoul of the standard. > > > Comment 4 > by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22 > Actually, the problem only occured after we converted the code from gcc-2.9x > to > gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands > and > thousands), so maybe we should try again to compile without the > -fno-strict-aliasing, and see if gcc will point us to some places where we do > dangerous things. The code does some very scary things manipulating objects > directly, by byte-offsets for instance. > I think it's pretty easy to reproduce the problem, it basically renders the > cache completely useless, returning objects of size 0 or 1. > > > Comment 5 > by Ed Hall 4 years ago at 2006-03-03 16:44:04 > Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't > part of the -O2 optimizations on gcc 2.95, but got added sometime during gcc 3 > development. > > > Comment 6 > by Ed Hall 4 years ago at 2006-03-03 16:46:43 > (Just to be clear, -fstrict-aliasing was *available* with gcc 2.95.3, it just > wasn't activated by the -O optimization flags.) > -- This message was sent by Atlassian JIRA (v6.2#6252)