This is the mail archive of the 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 astrees

On Thu, 13 Dec 2001, Richard Henderson wrote:
> On Thu, Dec 13, 2001 at 09:35:08AM -0800, Linus Torvalds wrote:
> > But Jason is, I think, really trying to argue for the opposite, namely
> > that if you don't use the value of an lvalue, it doesn't get dereferenced.
> You've completely ignored the lvalue-to-rvalue conversion
> part of Jason's argument.

I have _not_.

I'm saying that it has no _relevance_.

Read my email again.

In particular, read the analogy with just the expression "p".

Everybody agrees that that expression is an lvalue, no?

Everybody agrees that gcc will, when "p" is volatile, generate code to
read the value of "p", no?

These are statements of FACT. If you don't agree with me, then I don't
know what I can say - you're ignoring reality. That's a really good way to
argue, because nobody can argue against you, but that is NOT an argument
that you should use when deciding on what a C/C++ compiler should do or
not do.

In short: we convert that lvalue to a rvalue, because the expression has a

Whether the conversion happens or not is not dependent on whether the
value is used or not. Whether the conversion happens or not is _purely_ an
issue of whether the lvalue is the target of a assignment.

Read my email again. Please.

The issue of whether the value is used or not is NOT a semantic issue in C
or C++. It is purely an optimization issue. And optimization does not
change the meaning of a program, and in particular they do NOT remove
loads from volatile variables.

I'm not ignoring Jasons arguments. I'm refuting them with logical means,
and claiming that the arguments are _bogus_.


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