This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined astrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Cc: <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at codesourcery dot com>
- Date: Tue, 25 Dec 2001 08:19:50 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined astrees
On Wed, 26 Dec 2001, Fergus Henderson wrote:
> "What constitutes an access to an object that has volatile-qualified type is
> implementation-defined." That seems pretty clear to me.
> An implementation could say that *nothing* constitutes access to an
> object of volatile-qualified type, and could then entirely ignore
> volatile (except in as far as type checking and the effects on
> setjmp()/longjmp() are concerned).
Absolutely. Which is why I sayd it could play towers-of-hanoy if it wanted
to, but I claimed that from a QoI standpoint lcc was completely bogus.
Also, you're ignoring the difference between "undefined" and
"implementation defined". Go read that part of the standard again,
For example: I claim that it's ok to play towers-of-hanoy on "access" to a
volatile object, but because behaviour is _implementation_defined_ rather
than undefined, the compiler should (a) _document_ the choice to do so,
and (b) do so consistently (or document when it doesn't).
In contrast, you seem to think that implementation-defined means that the
compiler can choose to ignore the rules of C, and not just choose "what
constitues an access", but lcc _also_ seems to choose when to do the
access and when _not_ to do the access.
And that is BUGGY.