Re: gcc3 vs 176.gcc

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 10 Jan 2002, Joe Buck wrote:

> Generating code that does what the programmer intended is a good thing.
> Not telling the programmer that s/he messed up is *not* a good thing,
> because further maintainance of the program might prevent GCC from "DWIM"
> successfully.  As mentioned, on the RTL code on i386 we can tell by
> looking at the RTL that there is aliasing even though the language says
> there can't be, but evidently on the ia64 architecture we won't be
> able to tell, because the structure comes out differently.

Would mid-level RTL help do this more predictably?

Warnings based on the source code and controlled by appropriate options
(maybe within -Wall) make sense.  Removing the alias optimisations when
such warnings are given is more dubious, except where we know the declared
type and know that the access must be bad (e.g. float f; *(int *)&f;).

> In any case, like you with the kernel, the GCC maintainers can and will
> say to the people who want this feature (modify the alias set information
> if certain types of bad-but-obvious code is detected) implement the
> feature and send the patch in if they really want it.

I don't think we can provide a DWIM feature that reliably allows people to
use code breaking the ISO rules and have it "work".  What would make more
sense would be a type attribute that makes a type act like a character
type from the point of the alias rules, so you could do int i; *(short
(__attribute__((__may_alias__)) *))&i);.

-- 
Joseph S. Myers
jsm28@cam.ac.uk