------- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 07:27 -------
Subject: Re: gcc -O2 discards cast to volatile
"schlie at comcast dot net" <[EMAIL PROTECTED]> writes:
| (In reply to comment #35)
| > Subject: Re: gcc -O2 discards cast to volatile
|
| I apologize for interjecting, but wanted to verify my perception the
| conclusions reached; are they essentially?:
|
| - although an object referenced through a qualified lvalue which differs
| from that object's declaration may result in an undefined behavior (as
| an implementation may specifically allocate objects based upon their
| respective qualification, therefore may result in an unanticipated
| behavior if referenced as being dissimilarly qualified).
|
| - that object should be effectively be treated as specified by that
| qualified lvalue unless the compiler knows factually that it's
| correspondingly implied side effects will not affect the program's
| otherwise specified behavior.
|
| (where lvalue in this context is any object's reference,
| which may refer to either a source, or destination value.)
|
| Therefore:
|
| int i;
| const int ci:
| volatile int vi;
|
| *(int*)&ci = 0; // should treat ci as int, although may result in
| // unexpected behavior as const may be read-only.
This is undefined behaviour and on plateforms where GCC put const
object in read-only sections, you're in serious troubles. Other
compilers may do more "interesting" things, or less.
| int* foo(const int * ci){
| return (int*)ci;
| }
| *(foo(ci)) = 0; // as above.
Yes, again undefined behaviour.
| *(int)&vi = 0; // should treat as non-volatile, although may
| // may result in unexpected behavior if special
| // volatile things happen when a volatile allocated
| // object is physically addressed for example.
undefined behaviour -- assuming you meant *(int*)&vi -- quotes from
the standard already provided.
| *(volatile int*)&i = 0; // should treat as volatile, although may
| // result in unexpected behavior if true
| // volatile objects need to be declared as
| // such to be specially allocated to satisfy
| // an implementation's defined behavior.
This is unclear, reported in past and considered bugs is user codes as
far as GCC is concerned. gcc2eran thinks this should be accepted.
The issue is further confused by the fact that C has a rather
interesting formulation of its object model.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
