[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From hugh at mimosa dot com 2005-07-17 08:04 --- There is a thread on the gcc at gcc.gnu.org mailing list discussing this. A possible fix to GCC4.x has been posted in that thread: http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-17 16:36:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- 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
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-16 16:35 --- Subject: Re: gcc -O2 discards cast to volatile hugh at mimosa dot com [EMAIL PROTECTED] writes: [...] | If GCC (a) wants to be C99-conforming, and (b) wants to provide useful | semantics for `volatile', this is a bug. Based on discussions via private mails, I've become even more convinced that we should just honor the volatile access as written by the programmer. Furthermore, this should be clearly documented. Patches are welcome! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
neroden at gcc dot gnu dot org [EMAIL PROTECTED] writes:
[...]
| of an arbitrary memory address. If the underlying object has
| to be volatile, how do we make it volatile? Can we simply create a new
| underlying object by throwing in a temporary pointer variable? Is
something
| like the following sufficient to force an access?
|
| static inline unsigned char myMmioIn8(volatile void* base,
| const unsigned long offset)
| {
| volatile CARD8 * tmp = (CARD8*)base + offset;
| return *tmp;
| }
If is fragile. If the compiler does more aggressive inline (which I
hope 4.0 doesn't, but 4.x may at some point) and discover that the
chains of conversion started with something it thinks really not
volatile, then it would behave the same way as with the macro.
| # define MMIO_IN8(base, offset) myMmioIn8(base, offset)
|
| If that's not sufficient, I don't see any way to accomplish the required
| behavior under gcc 4.0 (without massive rewriting of the X.org code), so I
| hope it is.
I've come to believe that GCC's current choice is needlessly
unhelpful. I think it is much more reasonable to have GCC leave its
optimizer fingers out of the access through volatile lvalue, whether
the object behind is really defined volatile of not -- GCC cannot
know and the programmer cannot if is the object behind is actually
never defined, but is mapped to a memory. Unfortunately, I don't know
the extent of the GCC code that needs to be fixed so I don't know
whether it is fixable in 4.0.
-- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-15 07:51 ---
Subject: Re: gcc -O2 discards cast to volatile
neroden at gcc dot gnu dot org [EMAIL PROTECTED] writes:
[...]
| of an arbitrary memory address. If the underlying object has
| to be volatile, how do we make it volatile? Can we simply create a new
| underlying object by throwing in a temporary pointer variable? Is
something
| like the following sufficient to force an access?
|
| static inline unsigned char myMmioIn8(volatile void* base,
| const unsigned long offset)
| {
| volatile CARD8 * tmp = (CARD8*)base + offset;
| return *tmp;
| }
If is fragile. If the compiler does more aggressive inline (which I
hope 4.0 doesn't, but 4.x may at some point) and discover that the
chains of conversion started with something it thinks really not
volatile, then it would behave the same way as with the macro.
| # define MMIO_IN8(base, offset) myMmioIn8(base, offset)
|
| If that's not sufficient, I don't see any way to accomplish the required
| behavior under gcc 4.0 (without massive rewriting of the X.org code), so I
| hope it is.
I've come to believe that GCC's current choice is needlessly
unhelpful. I think it is much more reasonable to have GCC leave its
optimizer fingers out of the access through volatile lvalue, whether
the object behind is really defined volatile of not -- GCC cannot
know and the programmer cannot if is the object behind is actually
never defined, but is mapped to a memory. Unfortunately, I don't know
the extent of the GCC code that needs to be fixed so I don't know
whether it is fixable in 4.0.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From neroden at gcc dot gnu dot org 2005-07-15
05:50 ---
OK, so in X.org, the key area where this is hit is the definition of
MMIO_IN8 in compiler.h. For alpha, sparc, and powerpc, inline volatile
ASM is used instead (much better in some ways).
The vanishing line is:
(void) minb(hwp-IOBase + VGA_IN_STAT_1_OFFSET);
This expands in preprocessing to:
(void) MMIO_IN8(hwp-MMIOBase, (hwp-MMIOOffset + (hwp-IOBase +
VGA_IN_STAT_1_OFFSET)))
which further expands in preprocessing in compiler.h (except for
sparc, alpha and powerpc) to:
(void) *(volatile CARD8 *)( (CARD8*)(hwp-MMIOBase) + hwp-MMIOOffset +
hwp-IOBase + VGA_IN_STAT_1_OFFSET)
The key expansion is this one:
# define MMIO_IN8(base, offset) \
*(volatile CARD8 *)(((CARD8*)(base)) + (offset))
This obviously doesn't work and perhaps it shouldn't work. But what is a
good alternative implementation? Essentially, we're trying to force a read
of an arbitrary memory address. If the underlying object has
to be volatile, how do we make it volatile? Can we simply create a new
underlying object by throwing in a temporary pointer variable? Is something
like the following sufficient to force an access?
static inline unsigned char myMmioIn8(volatile void* base,
const unsigned long offset)
{
volatile CARD8 * tmp = (CARD8*)base + offset;
return *tmp;
}
# define MMIO_IN8(base, offset) myMmioIn8(base, offset)
If that's not sufficient, I don't see any way to accomplish the required
behavior under gcc 4.0 (without massive rewriting of the X.org code), so I
hope it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
-- What|Removed |Added CC||james at juranfamily dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 05:09
---
(In reply to comment #32)
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
(my quote above should read the other *direction* is simply undefined)
Uhm? It's just the passage you quoted earlier:
If an attempt is made to refer to an object defined with a volatile-qualified
type through use of an lvalue with non-volatile-qualified type, the behavior is
undefined.
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
It refers to it through an lvalue whose type is volatile int, which *is*
volatile-qualified.
My understanding is that you have gotten everything backwards.
In what sense?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gdr at integrable-solutions dot net [EMAIL PROTECTED] writes:
| | Still, consider the following variant:
| |
| | void quux(int *bar) {
| | *(volatile int*)bar = 42;
| | }
| |
| | volatile int foo;
| | quux((int*)foo);
| |
| | This time there is no attempt [...] to refer to an object defined with a
| | volatile-qualified type through use of an lvalue with non-volatile-qualified
| | type.
|
|
| Really?
that comment is wrong, sorry. You're right. (time for me to go to bed).
Yes, this is a bug in GCC.
-- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 05:11 ---
Subject: Re: gcc -O2 discards cast to volatile
gdr at integrable-solutions dot net [EMAIL PROTECTED] writes:
| | Still, consider the following variant:
| |
| | void quux(int *bar) {
| | *(volatile int*)bar = 42;
| | }
| |
| | volatile int foo;
| | quux((int*)foo);
| |
| | This time there is no attempt [...] to refer to an object defined with a
| | volatile-qualified type through use of an lvalue with non-volatile-qualified
| | type.
|
|
| Really?
that comment is wrong, sorry. You're right. (time for me to go to bed).
Yes, this is a bug in GCC.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 06:59 --- (In reply to comment #34) OK, that was just a demonstration of of the problem you pointed out in comments 9 and 12 and example (a) of comment 16. In this case, your analysis (be conservative) and my reading of the standard (comment 23) lead to identical conclusions. This leaves example (b) of comment 16, where the real object is non-volatile. Here we seem to still disagree: you said it's a QoI and not well-founded on the C standard, hence currently not a bug and fixing it would be a gcc extension. I argued, in comment 23, that this too is a bug, since the standard says that any access to an lvalue with volatile-qualified type must be left untouched. But this case seems to fall under PR 21568, which I believe should be reopened. For convenience I copied the relevant parts of comment 23 to that PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- 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
[Bug c/22278] gcc -O2 discards cast to volatile
--- 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
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From schlie at comcast dot net 2005-07-03 07:54 --- (In reply to comment #39) Subject: Re: gcc -O2 discards cast to volatile So unfortunately, again the question which comes to mind is what should happen when a program specifies an undefined behavior? Personally it seems most generally useful to warn that the behavior is undefined, but treat the objects as specified, as would be expected. (as the alternative would neither be expected nor well defined) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 16:48 --- See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. This is allowed by the C and C++ standards. *** This bug has been marked as a duplicate of 21568 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From olivier dot baudron at m4x dot org 2005-07-02
16:59 ---
I am not sure this is the same problem.
Besides, the following code is *not* optimized away with -O2:
void test (volatile char *addr) {
*addr;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:03 --- Did you read the message which I referenced? it is still not a bug if you read the message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 17:33 --- I see a difference here in that gcc doesn't know whether the referenced object is declared to be volatile, it isn't visible as in PR 21568. IMHO we actually have a bug here; I don't see anything in the standard which allows omitting the access here. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 17:42 --- Since the orginal pointer is not violatile the cast will not change any thing since the compiler can deduce it is not violatile. From C99, 5.1.2.3 P3: In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including anycaused by calling a function or accessing a volatile object). and since violatile applies the type which is being pointed to and not to the pointer, the compiler can deduce it is not needed. Casting away the violatile in a pointer changes the behavior (just like const). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 17:53 --- (In reply to comment #5) Since the orginal pointer is not violatile the cast will not change any thing since the compiler can deduce it is not violatile. It could deduce that if it was invalid to form a pointer to non-volatile that points to a volatile object. However, I can't see any point in the standard that disallows this. So how can gcc deduce the pointed-to object is not volatile? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 22:07 --- Prior versions of gcc did respect casts to pointer-to-volatile and did not optimize away the access. I've seen a lot of code that relies on that, and which would thus be broken by gcc 4.x (in a subtle and hard-to-debug way). One recent example is an elusive bug in Fedora Core 4's X.org package which bit many users (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242). I can't imagine a programmer casting into a pointer to volatile without really meaning it, so if the behavior is not defined by the standard then both compatibility and the principle of least astonishment seem to suggest reverting to the old behavior. -- What|Removed |Added CC||gcc2eran at tromer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:08 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:10 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Did you read the message which I referenced? Not just because people disagrees with your view means that they did not read what you wrote. | it is still not a bug if you read the message. I read the message and it bears no ressemblance to the specific case at hand here. Please stop closing PR based on half-digested material. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:10 --- Subject: Re: gcc -O2 discards cast to volatile falk at debian dot org [EMAIL PROTECTED] writes: | I see a difference here in that gcc doesn't know whether the referenced | object is declared to be volatile, it isn't visible as in PR 21568. Fully agreed. | IMHO we actually have a bug here; I don't see anything in the standard which | allows omitting the access here. again agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:11 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Since the orginal pointer is not violatile How do you know that? Just looking at function *parameter*? Sorry, that is no reason. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:12 --- Subject: Re: gcc -O2 discards cast to volatile falk at debian dot org [EMAIL PROTECTED] writes: | According to Joseph Myers, the question is whether this counts as access to | a volatile object, which is implementation defined (6.7.3#6). However, | extend.texi doesn't answer this, so I'll reopen it as a documentation problem. | We could then either document it does not constitute an access, or change | the behavior and state that it does. | | | -- |What|Removed |Added | | Status|RESOLVED|UNCONFIRMED |Keywords||documentation It is also wrong-code. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 22:19 --- (In reply to comment #8) I can't imagine a programmer casting into a pointer to volatile without really meaning it, so if the behavior is not defined by the standard then both compatibility and the principle of least astonishment seem to suggest reverting to the old behavior. I agree in principle. It might just turn out to be too hard to guarantee, in which case we might as well document that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 22:20 --- (In reply to comment #13) It is also wrong-code. This is the opposite view of what JSM said on IRC. Take it up with him if you believe otherwise. Basically this is all implemention defined and since we did not document before, we have a chance to define it to what we want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:20 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | Prior versions of gcc did respect casts to pointer-to-volatile and did not | optimize away the access. I've seen a lot of code that relies on that, and which | would thus be broken by gcc 4.x (in a subtle and hard-to-debug way). One recent | example is an elusive bug in Fedora Core 4's X.org package which bit many users | (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242). | | I can't imagine a programmer casting into a pointer to volatile without really | meaning it, so if the behavior is not defined by the standard then both | compatibility and the principle of least astonishment seem to suggest reverting | to the old behavior. We must be careful in distinguishing between the following two situations: (1) volatile int foo = 0; *(volatile int*) (int*) (foo); (2) int bar = 0; *(volatile int*) (bar); The former is well-formed and GCC should be careful. In the specific case at hand, the first cast may be passed to the function that is subject of this PR, and GCC has no way of knowing what is going behind the scene. Consequently, it must make the conservative assumption. The latter is just not well-founded based on the C standard. It is a QoI whether GCC should honor it or not. I have no strong opinion there, except saying that it is questionable. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:39 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | (In reply to comment #13) | | It is also wrong-code. | | This is the opposite view of what JSM said on IRC. Sorry, I do not follow IRC, and it would be unfortunate that PRs get closed based on claims we do not have logs for so that users and people can look at them and scrutinize. Furthermore, the fundamental issue is whether this *(volatile int*) (int*) (foo); (or equivalent) where foo has been defined volatile int should be treated differently from *(volatile int*) (foo); or foo; For all useful purposes, it helps remembering that GCC is not an academic exercise in C standard reading. | Take it up with him if you believe otherwise. | Basically this is all implemention defined and since we did not | document before, we have a chance to define it to what we want. and it is hard to believe we (GCC developers aiming at useful compiler, as opposed to students doing academic exercise) will define it to be either contradictory or the most useless as possible. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02 22:49 --- For all useful purposes, it helps remembering that GCC is not an academic exercise in C standard reading. Ok, then all of your comments about extensions to C++ should be thrown out the window since I know you are against extensions. If someone is going to program in C or C++, they should know they are going to get into trouble when programming and get something different than what they expect and should go read the standard to double check if they got it right or the compiler is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- (In reply to comment #17) Furthermore, the fundamental issue is whether this *(volatile int*) (int*) (foo); (or equivalent) where foo has been defined volatile int should be treated differently from *(volatile int*) (foo); or foo; How about this? int foo; *(volatile int*) (foo); In other words, why should the compiler bother at all with the qualifiers of what the pointer really points to? It seems simplest and most natural to decree that any dereference of a pointer-to-volatile (regardless of its origin) is to be treated as volatile and thus never optimized away. In other words, volatile should treated as a property of the type of the pointer being dereferenced, not of the actual object being pointed to. By analogy, if I write long bar = 42; x = *(char*)bar; then the compiler won't optimize this (into a SEGV?) just because it can easily tell that bar didn't really originate from a char*. Rather, it will take my word that (char*)bar should be treated just like any char*. Sure, it might optimize this subject to the usual semantics of char* -- but in case of volatiles, these semantics (should) forbid certain optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From falk at debian dot org 2005-07-02 23:45 --- (In reply to comment #19) How about this? int foo; *(volatile int*) (foo); In other words, why should the compiler bother at all with the qualifiers of what the pointer really points to? Because the standard says so. As Nathan Sidwell explains in the thread linked above, it would be both pretty difficult to define the language extension you want semantically clean, and to implement it in gcc. So nobody tried yet. (Giving a warning would probably be less difficult to implement, unfortunately nobody tried either.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 23:54 --- Subject: Re: gcc -O2 discards cast to volatile pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | For all useful purposes, it helps remembering that GCC is not an | academic exercise in C standard reading. | Ok, then all of your comments about extensions to C++ should be | thrown out the window No, you just chose to selectively misread statements. That is unfortunate, but we have to live with it. | since I know you are against extensions. You know nothing about me, so lease stick to GCC. | If someone is going to program in C or C++, they should know they are | going to get into trouble when programming and get something | different than what they expect and should go read the standard to | double check if they got it right or the compiler is correct. yes, but that is orthogonal to the issue at hand. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- | (In reply to comment #17) | Furthermore, the fundamental issue is whether this | | *(volatile int*) (int*) (foo); | | (or equivalent) where foo has been defined volatile int should be | treated differently from | | *(volatile int*) (foo); | | or | | foo; | | How about this? | | int foo; | *(volatile int*) (foo); It was included in my previous message. | In other words, why should the compiler bother at all with the qualifiers of | what the pointer really points to? Because the language definition says that the compiler should preserve a semantics and the compiler better bothers. | It seems simplest and most natural to | decree that any dereference of a pointer-to-volatile (regardless of | its origin) is to be treated as volatile and thus never optimized | away. In other words, volatile should treated as a property of the | type of the pointer being dereferenced, not of the actual object | being pointed to. but that is a fundamental departure from the language semantics. Replace volatile with const -- both are qualifiers -- and observe the disaster that would ensue. The volatile cv-qualified is interesting in the sense that it is fuzzily defined, but there are identities that the compiler must preserve. -- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 00:03 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30 --- | (In reply to comment #17) | Furthermore, the fundamental issue is whether this | | *(volatile int*) (int*) (foo); | | (or equivalent) where foo has been defined volatile int should be | treated differently from | | *(volatile int*) (foo); | | or | | foo; | | How about this? | | int foo; | *(volatile int*) (foo); It was included in my previous message. | In other words, why should the compiler bother at all with the qualifiers of | what the pointer really points to? Because the language definition says that the compiler should preserve a semantics and the compiler better bothers. | It seems simplest and most natural to | decree that any dereference of a pointer-to-volatile (regardless of | its origin) is to be treated as volatile and thus never optimized | away. In other words, volatile should treated as a property of the | type of the pointer being dereferenced, not of the actual object | being pointed to. but that is a fundamental departure from the language semantics. Replace volatile with const -- both are qualifiers -- and observe the disaster that would ensue. The volatile cv-qualified is interesting in the sense that it is fuzzily defined, but there are identities that the compiler must preserve. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:19
---
(In reply to comment #22)
| int foo;
| *(volatile int*) (foo);
It was included in my previous message.
Then it's still eluding me, since your foo (the object?) was volatile.
| In other words, why should the compiler bother at all with the qualifiers of
| what the pointer really points to?
Because the language definition says that the compiler should preserve
a semantics and the compiler better bothers.
Of course, but please forgive my ignorance -- where does does the standard
prescribe these semantics? The N869 draft (I don't have the standard; is N869
best fall-back?) says this:
[6.7.3/6] An object that has volatile-qualified type may be modified in ways
unknown to the lementation or have other unknown side effects. Therefore any
expression referring to such an object shall be evaluated strictly according to
the rules of the abstract machine, as described in 5.1.2.3. [...]
All other references to the semantics volatile likewise talk about objects. So,
what is an object?
[3.15/1] object: region of data storage in the execution environment, the
contents of which can represent values
[3.15/2] NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1.
What indeed is the type of an object?
[6.3.2.1/1] [...] When an object is said to have a particular type, the type is
specified by the lvalue used to designate the object. [...]
And also, later on:
[6.5.3.2/4] The unary * operator denotes indirection. If the operand [...]
points to an object, the result is an lvalue designating the
object. If the operand has type pointer to type, the result has type
type. [...]
And just to be sure about whether volatile is part of the type thus specified
by the lvalue:
[6.2.5/26] [...] The qualified or unqualified versions of a type are distinct
types [...].
So the way I read it, the object designated by *(volatile int*)(anything) has a
volatile-qualified type and should thus be evaluated strictly according to the
rules of the abstract machine.
but that is a fundamental departure from the language semantics.
Replace volatile with const -- both are qualifiers -- and observe
the disaster that would ensue.
I must be showing my ignorance again, but what disaster would that be?
BTW, according to your interpretation, what is the standard-compliant behavior
of the following?
void quux(int *bar) {
*bar = 42;
}
volatile int foo;
quux((int*)foo);
I'm asking because as of 4.0.0, the assignment is optimized away by -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From joseph at codesourcery dot com 2005-07-03 01:27 --- Subject: Re: gcc -O2 discards cast to volatile On Sun, 3 Jul 2005, gcc2eran at tromer dot org wrote: Of course, but please forgive my ignorance -- where does does the standard prescribe these semantics? The N869 draft (I don't have the standard; is N869 best fall-back?) says this: Get the standard, not ancient drafts. As I pointed out on the gcc list a while back, N1124 is the result of merging C99 with TC1 and TC2 and is freely available on the WG14 site. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 01:42 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| but that is a fundamental departure from the language semantics.
| Replace volatile with const -- both are qualifiers -- and observe
| the disaster that would ensue.
|
| I must be showing my ignorance again, but what disaster would that be?
If when the compiler sees const T* p, it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
return *q;
}
If the compiler assumed that *q is effectively const, therefore cannot
have its value changed through *p, then the following assertion will fail
int i = 4;
assert(foo(i, i) == 16);
because the compiler could just return the cached value r.
There is more a pointer than just its type.
| BTW, according to your interpretation, what is the standard-compliant behavior
| of the following?
|
| void quux(int *bar) {
| *bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
[#5] If an attempt is made to modify an object defined with
a const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. If an
attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-
volatile-qualified type, the behavior is undefined.113)
The footnote says
113This applies to those objects that behave as if they were
defined with qualified types, even if they are never
actually defined as objects in the program (such as an
object at a memory-mapped input/output address).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 01:43 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | (In reply to comment #22) | | int foo; | | *(volatile int*) (foo); | | It was included in my previous message. | | Then it's still eluding me, since your foo (the object?) was volatile. It was my object bar. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:46 --- (In reply to comment #24) Thanks! None of the quotes and references in comment 23 changed in N1124. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From hugh at mimosa dot com 2005-07-03 01:53
---
[ see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162274 ]
I feel that he gcc documentation promises that there will be an access. The
documentation can change, but it is a contract between the implementer and the C
programmer. Breaking a contract is not very nice. Especially when it can cause
quiet subtle breakage of a program.
info gcc node Volatiles with title 6.1 When is a Volatile Object Accessed?
clearly says:
Less obvious expressions are where something which looks like an access
is used in a void context. An example would be,
volatile int *src = SOMEVALUE;
*src;
With C, such expressions are rvalues, and as rvalues cause a read of
the object, GCC interprets this as a read of the volatile being pointed
to.
Now it turns out that gcc4 does *not* optimize away the access in:
void test(char *addr)
{
volatile char *t = addr;
(void) (*t);
}
Surely the motivating example in this bugzilla entry should be covered by the
same logic.
--
What|Removed |Added
CC||hugh at mimosa dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 02:30
---
(In reply to comment #25)
If when the compiler sees const T* p, it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
return *q;
}
If the compiler assumed that *q is effectively const, therefore cannot
have its value changed through *p, then the following assertion will fail
int i = 4;
assert(foo(i, i) == 16);
because the compiler could just return the cached value r.
We need to distinguish between the semantics that that must be followed, and
optimizations that preserve these semantics. The way I understand it,
semantics-wise const is not a promise, it's only a requirement: it tells the
compiler that it can't change the object directly, that's all. Meanwhile, the
optimizer tries to do various optimizations that preserve the semantics, for
example by noting that variables don't change their values; but in your example
it can't make that assumption without aliasing analysis (which will fail), since
by itself the const-qualified argument guarantees nothing.
So the standard says the semantics are dumb: they considers just the type of the
dereferenced pointer and acts accordingly (forbid direct changes of consts,
apply strict abstrat machine for volatiles). But subject to those semantics, the
optimizer can be as smart as it wants. There's no contradiction here.
[#5] If an attempt is made to modify an object defined with
a const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. If an
attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-
volatile-qualified type, the behavior is undefined.113)
OK. Then the volatile-stripping direction can be handled arbitrarily.
(In reply to comment #26)
It was my object bar.
OK. I was looking at comment 17.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 02:54 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | [#5] If an attempt is made to modify an object defined with | a const-qualified type through use of an lvalue with non- | const-qualified type, the behavior is undefined. If an | attempt is made to refer to an object defined with a | volatile-qualified type through use of an lvalue with non- | volatile-qualified type, the behavior is undefined.113) | | OK. Then the volatile-stripping direction can be handled arbitrarily. I do not understand that comment. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:14
---
(In reply to comment #30)
| OK. Then the volatile-stripping direction can be handled arbitrarily.
I do not understand that comment.
I meant that we were mostly concerned about what the standard says about the
effect of casting (say) int* into volatile int*, but the other directly is
simply undefined.
Still, consider the following variant:
void quux(int *bar) {
*(volatile int*)bar = 42;
}
volatile int foo;
quux((int*)foo);
This time there is no attempt [...] to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-volatile-qualified
type. So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
would you fix that with an approach that construes the standard to require
following the type of the real object?
Could the standard intend something so convoluted, when the interpretation in
comment 23 makes things perfectly sensible, well-defined and (in principle) easy
to implement?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
Re: [Bug c/22278] gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
| Still, consider the following variant:
|
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
| So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
| would you fix that with an approach that construes the standard to require
| following the type of the real object?
|
| Could the standard intend something so convoluted, when the interpretation in
| comment 23 makes things perfectly sensible, well-defined and (in principle)
easy
| to implement?
My understanding is that you have gotten everything backwards.
-- Gaby
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 04:43 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of casting (say) int* into volatile int*, but the other directly is
| simply undefined.
That is what I do not understand. Could you point me to the relevant
passage of the C standard?
| Still, consider the following variant:
|
| void quux(int *bar) {
| *(volatile int*)bar = 42;
| }
|
| volatile int foo;
| quux((int*)foo);
|
| This time there is no attempt [...] to refer to an object defined with a
| volatile-qualified type through use of an lvalue with non-volatile-qualified
| type.
Really? What does quux() does to the object defined through foo then?
| So why does gcc 4.0.0 -O3 still optimize away the assignment? And how
| would you fix that with an approach that construes the standard to require
| following the type of the real object?
|
| Could the standard intend something so convoluted, when the interpretation in
| comment 23 makes things perfectly sensible, well-defined and (in principle)
easy
| to implement?
My understanding is that you have gotten everything backwards.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 05:18 --- Subject: Re: gcc -O2 discards cast to volatile gcc2eran at tromer dot org [EMAIL PROTECTED] writes: | --- Additional Comments From gcc2eran at tromer dot org 2005-07-03 05:09 --- | (In reply to comment #32) | | I meant that we were mostly concerned about what the standard says about the | | effect of casting (say) int* into volatile int*, but the other directly is | | simply undefined. | | That is what I do not understand. Could you point me to the relevant | passage of the C standard? | | (my quote above should read the other *direction* is simply undefined) the other direction was very ambiguous. [...] | Really? What does quux() does to the object defined through foo then? | | It refers to it through an lvalue whose type is volatile int, which *is* | volatile-qualified. yes, you're right. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
[Bug c/22278] gcc -O2 discards cast to volatile
--- Additional Comments From hugh at mimosa dot com 2005-07-03 05:40 --- Simple rule about const and volatile qualifiers (not restrict): the program can manipulate pointer values with and without their qualifiers. But when the program accesses an object that is a volatile object (i.e. defined, created, or fundamentally volatile), it must be via a volatile lvalue. And when the program accesses an object that was created const (defined, created, or fundamentally const), then it must not be modifying it. Optimizers must not presume more. Well, there is a tricky rule about aliasing in N1124 section 6.5 (see footnote 74 on page 68), based on the unqualified types. But we're only talking about qualifiers. And another about multiple modifications between sequence points -- again, not relevant here. So I think that gcc4 is wrong for this case: the access should not be optimized out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
