--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- 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/bugzill
--- 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 `vo
--- 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
--- 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 volatil
"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
|
--- 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).
--
What|Removed |Added
CC||james at juranfamily dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
--- 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?
Persona
--- 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
--- 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
--- 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 o
--- 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) {
| | *(
"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
--- 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.
>
--- 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.
--- 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
--- 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 arbi
"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
--- 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 abou
--- 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-qua
--- 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 =
--- 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 implemente
--- 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
--- 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
--- 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" wit
--- 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 semanti
--- 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
--- 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
"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)
--- 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
--- 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?
--- 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 differentl
--- 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 kn
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 functi
--- 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 b
--- 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 you
--- 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 abou
"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
--- 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
--- Additional Comments From falk at debian dot org 2005-07-02 20:38
---
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 documentat
--- 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 point
--- 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 evaluat
--- 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 whic
--- 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
--- 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?
--- 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
52 matches
Mail list logo
