This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: type based aliasing again


bernds@cygnus.co.uk (Bernd Schmidt) writes:

> > BTW, it seems to me that this `cast to union' is something particular
> > to gcc, not a general solution, right?  I mean, other compilers might
> > not pay as much attention to the unions as gcc does, since accessing
> > any type other than the one that was actually stored in the union is
> > undefined behavior anyway.
> 
> If, by "cast to union", you mean code of the form
> 
>    union foo
>    {
>       double a;
>       int b[2];
>    };
>    double x;
>    x = 2.0;
>    ((union foo *)&x)->b[1] = 0;
> 
> then this is not even going to work with gcc, regardless of whether
> -fstrict-aliasing is on or not.  We found code like this in some math
> library code here at Cygnus a few weeks ago.  The problem is that gcc's
> MEM_IN_STRUCT/MEM_SCALAR_P alias analysis will catch cases like this and
> determine that the integer memory access can't alias the variable x.

Sigh. I fixed the TCP code in the Linux kernel to (mostly) do that. It
is also compiled with -fno-strict-aliasing. If I understood you and
Jonathan right it may be misoptimized even in with that option, because it 
is not dependent on the type based analysis.

Any chance to fix that problem, or at least offer a flag to turn that
additional alias checking off?

-Andi

-- 
This is like TV. I don't like TV.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]