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

["Miles Libbey (JIRA)" <ji...@apache.org>]

-fstrict-aliasing optimizer generates bad code
----------------------------------------------

                 Key: TS-302
                 URL: https://issues.apache.org/jira/browse/TS-302
             Project: Traffic Server
          Issue Type: Improvement
            Reporter: Miles Libbey
            Priority: Minor


(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.
-
You can reply to this email to add a comment to the issue online.