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

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831116#comment-13831116 ] 

ASF subversion and git services commented on TS-302:
----------------------------------------------------

Commit a90c877e8eb76d92f9ddfdf510a90c32a4ab6478 in branch refs/heads/4.1.x from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a90c877 ]

TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x

Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of uin32_t. Simplify methods because of this."

This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.

This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable release.


> -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: 6.0.0
>
>         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.1#6144)