This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: An alias bug
- To: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Subject: Re: An alias bug
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 12 Jul 1998 23:14:57 -0600
- cc: hjl at lucon dot org, egcs-bugs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199807120617.XAA31802@dm.cobaltmicro.com>you write:
> I see this come up now and again, so I'm finally going to ask.
> How do we tell users they can take one type, and look at "pieces" of
> it, when they use gcc? Or are you saying that we declare "long long"
> as a special case in this regard?
Put them in a union and extract elements from the union.
Or use memcpy to extract the bits from one thing and put them in another
of a different type.
Or claim one of the things is volatile.
HJ's testcase basically as a useless cast to try and trip the "bug".
you can remove the whole ((long_long_type *)&u)->l[1] and replace it
with just (u & 0xffffffff). Actually HJ's testcase could just as
easily fail with gcc-2.7 since the "bug" it's trying to trigger exists
there too.
> There is a lot of legacy code out there which does this. One example
> is the "portable" generic IP networking checksum function provided in
> the BSD networking sources.
There's less and less of this code IMHO -- modern compilers have been
doing this kind of alias analysis for some time and as a result folks
have been forced to fix their code. Of course this doesn't apply to
Linux and some other free software projects since they only use gcc.
> If we now say "such code is bogus", we better have a game plan as to
> what we tell these people who have similar code which have worked for
> many years yet now barfs just like hj's test case.
Point them to the C standard :-) :-)
jeff