This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why 2.0.34 compiles with gcc 2.8.* and egcs, whereas 2.0.33 will not , work properly
- To: Wolfram Gloger <wmglo at dent dot med dot uni-muenchen dot de>
- Subject: Re: Why 2.0.34 compiles with gcc 2.8.* and egcs, whereas 2.0.33 will not , work properly
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 07 Jun 1998 00:49:14 -0600
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <19980606152449.1117.qmail@md.dent.med.uni-muenchen.de>you write:
> *(&eflags) = (eflags & 0xffffcfff) | (level << 12);
>
> Doesn't the mere presence of &eflags in the source constitute an alias
> and force the evaluation strictly according to the rules of the
> abstract machine, even without specifying `volatile' ? Otherwise, why
> would one write *(&x) anyway ?
No, it depends on the scope of eflags and other factors.
Consider a good dead store elimination optimizer (which we're slowly
adding the building blocks for). If "eflags" has function scope,
and no path from the store into &eflags has a load which might use
the same address, then the store to &eflags is dead and can be
deleted.
I believe this particular "bug" has already been classified by
Linus as a bug in Linux.
jeff