Re: module level flags

[Joe Buck <Joe dot Buck at synopsys dot com>]

[ aliasing rules ]
> FWIW, the fact that it works for unions is a GCC extension.  It is not
> guaranteed to work by the ISO C Standard, since, by the Standard,
> using a member of the union that was not the one that you initialized
> also invokes undefined behavior (unless you're accessing a common
> prefix of two different structs, yadda, yadda).

In practice, the case for unions will be supported by all compilers that
are acceptable to users: code to use unions to get at the bit-level
representation of floating-point numbers is required, and it is
well-understood to be implementation-dependent.  Without the ability to
write unions one way and read them another way, it's not possible to
write IEEE isnan() or isinf() routines in C; assembly would be needed.

> > So, to protect users from this catastrophe, you silently destroy
> > the efficacy of a pointer causing their programs to head south
> > without a discernible error or even a warning.
> 
> The program in question is wrong, and such errors can't be detected in
> general.  Of course detecting it in the few situations in which it is
> possible would be a useful contribution to GCC, but the cases in which
> it's really not obvious where the error is, the compiler is very
> unlikely to be able to figure it out either, because it would require
> information from multiple translation units.
> 
> > That's not a sufficient excuse for throwing up your
> > hands on being helpful and silently generate trash.
> 
> Garbage in, garbage out.

There is an argument for attempting to detect obvious cases of error, and
this would help users.  Some developers have objected that because not all
errors can be detected, this would give users a false sense of security
when they don't see any aliasing warnings.

> > either emit working code (as I suggest), or emit a hard error.

Use -fno-strict-aliasing if you don't want to learn the rules.  Your code
may be slower, but no matter.

> A hard error would probably be inappropriate, since the compiler can't
> tell in general whether the code in question would actually be
> executed, a condition necessary for the undefined behavior to actually
> be invoked.

At least in the case where the bad code is always reached if the function
is called, a hard error might be reasonable.