This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/22278] gcc -O2 discards cast to volatile
- From: "schlie at comcast dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Jul 2005 07:09:23 -0000
- Subject: [Bug c/22278] gcc -O2 discards cast to volatile
- References: <20050702164323.22278.olivier.baudron@m4x.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From schlie at comcast dot net 2005-07-03 07:09 -------
(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.
int* foo(const int * ci){
return (int*)ci;
}
*(foo(ci)) = 0; // as above.
*(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.
*(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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278