Sender: nate AT cartsys DOT com
Message-ID: <37969D4B.609FBC62@cartsys.com>
Date: Wed, 21 Jul 1999 21:25:47 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: No more warnings...
References: <m116ZpN-000KuPC AT sloep101 DOT cs DOT vu DOT nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Incidentally, one of the big changes with gcc 2.95 is that the ANSI
aliasing rules are now strictly enforced by default.  The relevant docs
section follows:

----------------------------------------------------
-fstrict-aliasing 
     Allows the compiler to assume the strictest aliasing rules
applicable to the language being compiled. For C (and C++), this
activates
     optimizations based on the type of expressions. In particular, an
object of one type is assumed never to reside at the same address as an
object
     of a different type, unless the types are almost the same. For
example, an unsigned int can alias an int, but not a void* or a double.
     A character type may alias any other type. Pay special attention to
code like this: 

     union a_union { 
       int i;
       double d;
     };

     int f() {
       a_union t;
       t.d = 3.0;
       return t.i;
     }

     The practice of reading from a different union member than the one
most recently written to (called "type-punning") is common. Even with
     `-fstrict-aliasing', type-punning is allowed, provided the memory
is accessed through the union type. So, the code above will work
     as expected. However, this code might not: 

     int f() { 
       a_union t;
       int* ip;
       t.d = 3.0;
       ip = &t.i;
       return *ip;
     }

     Every language that wishes to perform language-specific alias
analysis should define a function that computes, given an tree node, an
alias
     set for the node. Nodes in different alias sets are not allowed to
alias. For an example, see the C front-end function c_get_alias_set. 
-------------------------------------------------

Linux, for example, is having some troubles with this, since the kernel
is full of such code, and currently GCC will handle it by generating the
"wrong" code but not issuing warnings.  Before gcc 2.95 comes into wide
use, it might be wise to audit libc for suspicious code and fix it.  Or
else, arrange to compile it with -fno-strict-aliasing.
-- 

Nate Eldredge
nate AT cartsys DOT com