From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen To: bernds@cygnus.co.uk Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: References: X-SW-Source: 1999-09n/msg00542.html Message-ID: <19990930180200.PSGJCJFW3TzxhNT0B1RyVz07EMvWRkGa3vCN7mUW3e4@z> 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.