[
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-302:
-----------------------------
Fix Version/s: (was: sometime)
3.5.0
> -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
> Priority: Minor
> Fix For: 3.5.0
>
> Attachments: no-no-fstrict-alias.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
