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 as trees

On Dec 14, 2001, Linus Torvalds <> wrote:

> On 14 Dec 2001, Alexandre Oliva wrote:
>> On Dec 14, 2001, Linus Torvalds <> wrote:
>> > 	int c;

>> > 	(char) c;

>> > then that expression _is_ in fact an lvalue (in gcc, not in C in general),

>> volatile int c;
>> (volatile char)c;
>> Do I read a char or an int from c's address?

> Don't shoot the messenger.

I was just asking a legitimate question, whose answer I'd really like
to know.  Sorry if you it sounded otherwise.

And, now that I think of it, how about (void)c, given a volatile c.
Do we read from c or not, given that reading from a void lvalue is
utter nonsense?

> And I didn't ask for it, nor code it. Nobody saw me do it, you can't pin
> this one on me. I'm innocent.


> 	(int)a = 5
> 	(int)(a = (char *)(int)5)

> In fact, now that I look at it more closely, the actual "lvalue" stays the
> same (ie we always assign to _a_, not to some sub-part of a, and the thing
> it changes is really the type of the values stored, and the return value
> of the assignment. The actual accesses are always done in the type of the
> original lvalue.

Good.  (int)a is not equivalent to *(int*)a when you read from a, so
why should it be when assigning to it.  So this is better thought out
that it appeared to be at first, and it clears any doubt on what
should be read in the case above.

> 	volatile int p, q, r;

>         ((char)p = q) = r;

> equivalent to

> 	(char) (p = (char)q);
> 	(char) (p = (char)r);

> I think.


>> And now, an easy question: is this yet another GCC extension whose
>> consequences were not fully thought-out in advance? :-)

> [ Innocent look ] Why do you ask?

Just wondering :-)  It turned out that question was a tricky one,
indeed :-)

> Anyway, in this case I think that the extension has well-defined behaviour
> thanks to having an actually _documented_ equivalence. You didn't expect
> that, did you ;)

Would anyone? :-)

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
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]