public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hugh at mimosa dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/22278] gcc -O2 discards cast to volatile Date: Sat, 16 Jul 2005 16:35:00 -0000 [thread overview] Message-ID: <20050716161806.9362.qmail@sourceware.org> (raw) In-Reply-To: <20050702164323.22278.olivier.baudron@m4x.org> ------- Additional Comments From hugh at mimosa dot com 2005-07-16 16:18 ------- Here is some C Lawyering from Henry Spencer. I asked him to look at and comment on this bug. With his permission, I'm quoting his response here. There is little room for compiler writers to maneuver here, unless they have announced their intentions in advance in their documentation. Reading C99 carefully: 6.5.3.2: applying `*' to a pointer of type `T *' which points to an object yields an lvalue of type `T' designating that object. So the lvalue in the assignment has a volatile-qualified type. 6.3.2.1: when an object is said to have a particular type, the type is specified by the lvalue used to designate the object. So the lvalue having a volatile-qualified type *means* that the object it designates has a volatile-qualified type; "has type X" and "is designated by an lvalue of type X" are synonymous (!). 6.7.3: any expression referring to an object of volatile-qualified type must be evaluated strictly by the rules of the abstract machine, although precisely what constitutes an "access" to the object is implementation-defined. (Note, "implementation-defined" behavior is required to be well-defined and *documented*.) So if the reference in question is an "access", it must occur where the abstract machine says it should. 5.1.2.3: the abstract machine evaluates all expressions as specified by semantics and all side effects must occur, side effects including "accessing a volatile object"; implementations are allowed to skip part of expression evaluation only if they can deduce that no needed side effects (notably "accessing a volatile object") are therefore skipped. So if the reference is an "access", it must occur, period. I see no useful wiggle room in the difference between "access" and "accessing", or the difference between "volatile object" and "object of volatile-qualified type". These appear to me to be minor accidents of inconsistent terminology, not useful to a sane implementer. 6.7.3 says that to refer to an object "defined with" volatile-qualified type "through use of an lvalue" with non-volatile-qualified type yields undefined behavior. However, the reference here uses a volatile-qualified lvalue, so this is not relevant. A pointer value is not an lvalue; there is no lvalue present until the `*' operator is applied. Surprising though it might seem, I see no express or implied permission to distinguish based on whether the object in question was *defined* with a volatile-qualified type. There are places in the standard where how an object is defined is significant, e.g. the rules for `const' and the part of 6.7.3 noted in the previous paragraph, but none of them is part of the chain of reasoning above. The only loophole is the definition of "access". If GCC wishes to claim standard conformance, GCC is required to document its definition. I'm not aware of any mention of this in the GCC documentation, although I haven't dug hard for it. I see no room for a reasonable definition of "access" which retains some useful meaning for `volatile' and doesn't cover the reference in question. (I agree that you can contrive a definition which contains special-case wording to cover this case, but not that it's reasonable to do so.) If GCC (a) wants to be C99-conforming, and (b) wants to provide useful semantics for `volatile', this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
next prev parent reply other threads:[~2005-07-16 16:18 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-07-02 16:43 [Bug c/22278] New: " olivier dot baudron at m4x dot org 2005-07-02 16:48 ` [Bug c/22278] " pinskia at gcc dot gnu dot org 2005-07-02 22:08 ` Gabriel Dos Reis 2005-07-02 16:59 ` olivier dot baudron at m4x dot org 2005-07-02 17:03 ` pinskia at gcc dot gnu dot org 2005-07-02 17:33 ` falk at debian dot org 2005-07-02 17:42 ` pinskia at gcc dot gnu dot org 2005-07-02 17:53 ` falk at debian dot org 2005-07-02 20:38 ` falk at debian dot org 2005-07-02 22:07 ` gcc2eran at tromer dot org 2005-07-02 22:08 ` gdr at integrable-solutions dot net 2005-07-02 22:10 ` gdr at integrable-solutions dot net 2005-07-02 22:10 ` gdr at integrable-solutions dot net 2005-07-02 22:11 ` gdr at integrable-solutions dot net 2005-07-02 22:12 ` gdr at integrable-solutions dot net 2005-07-02 22:19 ` falk at debian dot org 2005-07-02 22:20 ` pinskia at gcc dot gnu dot org 2005-07-02 22:20 ` gdr at integrable-solutions dot net 2005-07-02 22:39 ` gdr at integrable-solutions dot net 2005-07-02 22:49 ` pinskia at gcc dot gnu dot org 2005-07-02 23:30 ` gcc2eran at tromer dot org 2005-07-03 0:03 ` Gabriel Dos Reis 2005-07-02 23:45 ` falk at debian dot org 2005-07-02 23:54 ` gdr at integrable-solutions dot net 2005-07-03 0:03 ` gdr at integrable-solutions dot net 2005-07-03 1:19 ` gcc2eran at tromer dot org 2005-07-03 1:27 ` joseph at codesourcery dot com 2005-07-03 1:42 ` gdr at integrable-solutions dot net 2005-07-03 1:43 ` gdr at integrable-solutions dot net 2005-07-03 1:47 ` gcc2eran at tromer dot org 2005-07-03 1:54 ` hugh at mimosa dot com 2005-07-03 2:30 ` gcc2eran at tromer dot org 2005-07-03 2:54 ` gdr at integrable-solutions dot net 2005-07-03 4:14 ` gcc2eran at tromer dot org 2005-07-03 4:43 ` Gabriel Dos Reis 2005-07-03 4:43 ` gdr at integrable-solutions dot net 2005-07-03 5:11 ` Gabriel Dos Reis 2005-07-03 5:09 ` gcc2eran at tromer dot org 2005-07-03 5:11 ` gdr at integrable-solutions dot net 2005-07-03 5:18 ` gdr at integrable-solutions dot net 2005-07-03 5:40 ` hugh at mimosa dot com 2005-07-03 6:59 ` gcc2eran at tromer dot org 2005-07-03 7:09 ` schlie at comcast dot net 2005-07-03 7:27 ` gdr at integrable-solutions dot net 2005-07-03 7:54 ` schlie at comcast dot net 2005-07-05 2:17 ` james at juranfamily dot org 2005-07-15 6:41 ` neroden at gcc dot gnu dot org 2005-07-15 7:52 ` Gabriel Dos Reis 2005-07-15 8:10 ` gdr at integrable-solutions dot net 2005-07-16 16:35 ` hugh at mimosa dot com [this message] 2005-07-16 17:53 ` gdr at integrable-solutions dot net 2005-07-17 8:09 ` hugh at mimosa dot com 2005-07-17 16:59 ` rth at gcc dot gnu dot org 2005-07-19 20:28 ` [Bug tree-optimization/22278] " cvs-commit at gcc dot gnu dot org 2005-07-20 0:11 ` cvs-commit at gcc dot gnu dot org 2005-07-20 0:26 ` rth at gcc dot gnu dot org 2005-08-11 23:56 ` cvs-commit at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050716161806.9362.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).