[jira] [Updated] (TS-302) -fstrict-aliasing optimizer generates bad code

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

     [ 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