This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile MEMs in statement expressions and functions inlined as trees


On Dec  6, 2001, Jason Merrill <jason@redhat.com> wrote:

> However, the C++ standard says

>   The result of the assignment operation is the value stored in the left
>   operand after the assignment has taken place; the result is an lvalue.

> in C++, *q should be read
> after the store

I'm not sure this can be derived from the sentence above.  After all,
the result of the assignment *is* the value stored, just it's an
lvalue.  It doesn't imply, to me, that the value should be re-loaded
should it be needed.  Perhaps I'm missing some other passage of the
Standard?

> In C, it should not.

I'm not positive this can be guaranteed, but it sounds quite
reasonable, indeed.  However, the reference to the ANSI C Standard
makes me wonder if the re-loading was guaranteed in some earlier
version of the C Standard.

> In neither language should anyone write anything like the example if
> they're dealing with volatiles.

Would your restriction be extended to constructs such as:

int bar, volatile *vpi;
int foo = ({ *vpi = bar; });

In this case, should *vpi be re-loaded or not?  Does it matter if it's
C or C++?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]