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 inlinedastrees



On 15 Dec 2001, Alexandre Oliva wrote:
>
> But I begin to see light at the end of the tunnel.  Since the standard
> says what constitutes an access is unspecified, implementations are
> free to choose whatever makes the most sense for them, or for their
> users :-)

Well, you'd _hope_ that it's for "their users".

> I suppose we could say that an lvalue constitutes an access only if
> its result, as an rvalue, is used.

Now, PLEASE don't go down that path. That way lies madness.

I'll give you an example:

	volatile int p;

	int foo(void)
	{
		return p;
	}

	int main(void)
	{
		foo();
		return 0;
	}

Now, compile the above with -O3, and watch "foo" be inlined.

Is the rvalue of "p" actually "used" or not?

>From a syntactic standpoint, looking at just "foo()", yes.

>From a _semantic_ standpoint, depending on how well you analyze the
program, equally clearly the answer is "no". The optimizer will get rid of
all uses (the _uses_ are certainly not volatile).

Basically, "use" is a REALLY BAD thing from a semantic standpoint - the
semantics of whether something is used or not often depends on how hard
you look at the problem.

So if you start making decisions based on "use", then you will always
fight behaviour that changes due to subtle optimization issues etc.

Now, what about the "syntax-only" use?

I claim that it has the same problem: very slight syntactic sugar will
change behaviour subtly. For example, is something like

	({ p; })

is "syntactic use" or not? Nobody actually _uses_ the value, but the
compiler might, depending on internal implementation issues, consider this
equivalent to "using" the value of "p" as the "value of the compound
statement".

Or is just the simple statement

	p;

a "use" of the value? I agree with rth that you can always claim that it
is "implementation dependent", but can you claim that it is _consistent_?
I don't think you can.

If the lvalue-statement "p;" is considered to be a use of the rvalue, then
why is not the lvalue-statement "p = 0;" considered to have used _its_
rvalue?

Basically, any which way you define "use", you _always_ have problems. You
always have to explain you special cases, and special cases are _bad_,
even if they are implementation-defined.

> I.e., it appears that we're free to choose.  We just have to decide
> which semantics we want.

I'd much prefer to ask what the sane and _consistent_ semantics are that
can be clearly documented, and that are _not_ dependent on subtle issues
like "optimization" and non-local syntactic sugar.

Also, I still claim that the standard CLEARLY SAYS (5.17.1):

  "..the result of the assignment operation is the VALUE STORED.."

(emphasis mine).

Nobody has been able to refute that fact, and the best that people like
Gabriel have been able to come up with is to _ignore_ that part of the
standard.

And I will say that if I have

	volatile int *p;

and "p" points to a write-only IO memory area that on read always returns
zero, then a compiler that returns zero for the expression

	x = ... some computed non-zero-value ..
	return (*p = x);

is a _buggy_ compiler. That compiler is clearly _violating_ the sentence
of the standard that says that the return value of the assignment
expression is the value stored (which is non-zero).

Why do you and Gabriel _continue_ to ignore this very real sentence?

I've quoted the standard up and down, left and right, and NOBODY has been
able to refute the fact that the standard clearly says that the result of
an assignment is the value stored. I've shown that that part in _no_ way
violates the fact that the assignment is a lvalue.

And this is not an issue of "accesses to volatile memory are
'implementation defined'". This is a clear issue of _correctness_, where
current gcc behaviour does NOT match the language of the standard. Gcc
currently does NOT return the "value stored" like the standard mandates.

_Please_ don't just ignore that sentence fragment of the standard because
you don't like it or because you profess to not understand it like Gabriel
does. At least acknowledge it as a _bug_ in gcc.

			Linus


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