This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CVS Update: www.netwinder.org: pub
- To: Philip Blundell <Philip.Blundell@pobox.com>
- Subject: Re: CVS Update: www.netwinder.org: pub
- From: Andreas Schwab <schwab@suse.de>
- Date: 02 Sep 1999 10:43:08 +0200
- Cc: commitinfo@netwinder.org, gcc@gcc.gnu.org
- References: <E11MHSD-0003tN-00@kings-cross.london.uk.eu.org>
Philip Blundell <Philip.Blundell@pobox.com> writes:
|> >Log message:
|> > Fix for strange dma init error.
|>
|> Ho ho. The gist of this appears to be that if you compile this code like so:
|>
|> $ cat t.c
|> foo(int a)
|> {
|> if ((*(volatile unsigned char *)(a) == 0)
|> && (*(volatile unsigned char *)(a) == 1))
|> bar();
|> }
|> $ gcc -O2 t.c
|>
|> you will get no code generated for the if-statement - this seems to happen
|> with gcc 2.95 on both Intel and ARM. I don't have the C standard handy at
|> the moment but my understanding was that this ought to be valid and generate
|> the memory accesses and comparison. Any language lawyers care to comment?
Accessing a volatile object is a side effect, and the implementation is
only allowed to omit it if it can deduce that the side effect is not
needed (5.1.2.3 (Program execution) #2/#3 in the C9x draft). Since there
is a sequence point at the end of the first operand of the && operator,
all side effects from accessing the volatile object the first time must
take place before this point.
In other words, IMHO both accesses must actually be carried out, and due to
the volatile nature of the value this condition can well be true.
Andreas.
--
Andreas Schwab "And now for something
schwab@suse.de completely different."
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg