On Sun, Jul 17, 2005 at 11:56:46AM -0700, Geoffrey Keating wrote:
> "D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
> > An object that has volatile-qualified type may be modified in ways
> > unknown to the implementation or have other unknown side
> > effects. Therefore any expression referring to
On Friday, July 22, 2005, at 06:28 PM, Geoff Keating wrote:
I am discussing here only with what GCC *could* do, and still be
standards-conforming. What it *should* do is a different > conversation.
You will have to explain the benefits to me of having discussions on
this list of discussing th
(sorry, with intended statement this time)
> From: Geoff Keating <[EMAIL PROTECTED]>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
>
>>> Geoffrey Keating writes:
>
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(vol
> From: Geoff Keating <[EMAIL PROTECTED]>
> On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
>
>>> Geoffrey Keating writes:
>
>>> without 'volatile', then this object cannot be modified unknown to
>>> the implementation, even if someone also writes '(*(volatile int *)&i)
>>> = 1'.
>>
>> - merely me
On 22/07/2005, at 7:15 PM, Paul Schlie wrote:
Geoffrey Keating writes:
without 'volatile', then this object cannot be modified unknown to
the
implementation, even if someone also writes '(*(volatile int *)&i)
= 1'.
- merely means: treat the object being referenced as volatile
qualif
On 22/07/2005, at 7:57 PM, Gabriel Dos Reis wrote:
There is a "semantics of access". It is implementation-defined.
I think you're thinking of "what constitutes an access", which is
implementation-defined, but is not the same of the semantics of an
access.
The standard describes things
Geoff Keating <[EMAIL PROTECTED]> writes:
> This is part of what I meant by saying that your model isn't a match
> for the model in the standard. Your model had semantics attached to
> the access.
Despite evident appearances, I wasn't trying to make an argument from
the standard. I was trying t
Geoff Keating <[EMAIL PROTECTED]> writes:
| On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:
|
| > Geoffrey Keating <[EMAIL PROTECTED]> writes:
| >
| >> Although I can see that this is how you might think about the
| >> semantics of 'const' and 'volatile', I don't think they're an exact
| >> ma
> Geoffrey Keating writes:
>
> int i;
- merely means: allocate and treat all references to the object as
referencing an unqualified int object, unless re-qualified within a
more local scope.
> without 'volatile', then this object cannot be modified unknown to the
> implementation, even if som
On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:
Geoffrey Keating <[EMAIL PROTECTED]> writes:
Although I can see that this is how you might think about the
semantics of 'const' and 'volatile', I don't think they're an exact
match for the model in the standard. In fact, I think you could
ex
Geoffrey Keating <[EMAIL PROTECTED]> writes:
> > const is inherently a characteristic of the object. It applies at
> > definition time. Casting away const in a reference does not change
> > the definition. Whether making an assignment through a pointer after
> > casting away const is legal depe
Ian Lance Taylor writes:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > > In other words, we're asked to agree that the type of an object
> > > changes depending on how it is accessed.
> > > For the benefit of readers, only the first sentence of this para is
> > > the language of the standard
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
> 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
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> Paul Schlie <[EMAIL PROTECTED]> writes:
>
> | > Gabriel Dos Reis writes:
> | > If by analysis, you can determine ...
> |
> | The problem with this type of logic is that it leads to arbitrary
> | inconsistent designation of an object's reference as a
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis writes:
| > If by analysis, you can determine ...
|
| The problem with this type of logic is that it leads to arbitrary
| inconsistent designation of an object's reference as a function of
| the breadth of the "analysis", therefore seem
> Gabriel Dos Reis writes:
> If by analysis, you can determine ...
The problem with this type of logic is that it leads to arbitrary
inconsistent designation of an object's reference as a function of
the breadth of the "analysis", therefore seems clearly undesirable.
Resulting in only two possibi
[EMAIL PROTECTED] (Kai Henningsen) writes:
| [EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 17.07.05 in <[EMAIL
PROTECTED]>:
|
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > | > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 17.07.05 in <[EMAIL PROTECTED]>:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> | > | You make it sound like the s
On Jul 17, 2005, at 4:48 AM, Gabriel Dos Reis wrote:
C++ has resisted, for two decades, the temptation of "improving" the
meaning of volatile :-) considering that it is C's baby.
Do you know what the semantics of:
a;
are in C and C++?
:-(
Mike Stump <[EMAIL PROTECTED]> writes:
| On Jul 17, 2005, at 4:48 AM, Gabriel Dos Reis wrote:
| > C++ has resisted, for two decades, the temptation of "improving" the
| > meaning of volatile :-) considering that it is C's baby.
|
| Do you know what the semantics of:
|
| a;
|
| are in C and
| From: Paul Schlie <[EMAIL PROTECTED]>
| > | void foo(void) {
| > |int *x = 4;
| > | *x = 3;
| The point I was attempting to make, was that just because a specified
| statement's effective behavior/side-effects are not well defined, it doesn't
| mean that it's clearly specif
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | - Just as if given:
> |
> | void foo(void) {
> |int *x = 4;
> | *x = 3;
The point I was attempting to make, was that just because a specified
statement's effective behavior/side-effects are not well defined, it doesn't
mean tha
On Sun, 17 Jul 2005, D. Hugh Redelmeier wrote:
> If GCC4 causes this much problem with X, I wonder what GCC4 will do to
> the Linux kernel.
Current combinations of the Linux kernel and GCC 4.0 seem to work just
fine, as far as I can tell.
Gerald
> From: Jonathan Wakely <[EMAIL PROTECTED]>
> On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:
>
>>> Note that I'm explicitly not taking a position on what the standard says.
>>> The standard is notoriously incomplete with respect to object model issues,
>>> including volatility, so I
Paul Schlie <[EMAIL PROTECTED]> writes:
| > From: Paul Schlie <[EMAIL PROTECTED]>
| >> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| >> I don't understand what you mean here. Are you seriously suggesting
| >> that
| >>
| >> int main(void) {
| >> const int x = 4;
| >> *(int*)
Paul Schlie <[EMAIL PROTECTED]> writes:
[...]
| > | With all due respect, unless there is an explicit reference in the
standard
| > | to contradict it's clearly stated requirement that an object's qualified
| > | lvalue ("locator value") designates the object being referenced, all
| > | interpr
> From: Paul Schlie <[EMAIL PROTECTED]>
>> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
>> I don't understand what you mean here. Are you seriously suggesting
>> that
>>
>> int main(void) {
>> const int x = 4;
>> *(int*)&x = 3;
>> }
>>
>> is well-defined?
>
> Actually y
- The assignment reference to x is valid as it's not specified as const,
therefore must be performed, unless:
You simply got the purpose of optimization and, to some extent,
high-level languages wrong. This thread shows that if people are
reasonable (on both sides) a solution will be found.
On Sun, Jul 17, 2005 at 09:29:11PM -0400, Paul Schlie wrote:
> > Note that I'm explicitly not taking a position on what the standard says.
> > The standard is notoriously incomplete with respect to object model issues,
> > including volatility, so I think that trying particularly hard to parse its
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | Paul Schlie <[EMAIL PROTECTED]> writes:
> | > Note that I'm explicitly not taking a position on what the standard says.
> | > The standard is notoriously incomplete with respect to object model
> | > issues, including volatility, so I think that tryi
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Note that I'm explicitly not taking a position on what the standard says.
| > The standard is notoriously incomplete with respect to object model issues,
| > including volatility, so I think that trying particularly hard to parse its
| > words in this ar
> Note that I'm explicitly not taking a position on what the standard says.
> The standard is notoriously incomplete with respect to object model issues,
> including volatility, so I think that trying particularly hard to parse its
> words in this area is probably not a good use of time for people
Daniel Berlin wrote:
On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I ho
> I did see Ian's summary,
>
> http://gcc.gnu.org/ml/gcc/2005-07/msg00714.html
>
> wherein he ascribed the semantics of the volatile qualifier to the
> access, and not to the object. I agree with his description completely,
> as I believe it embodies the intuition that C programmers have used
> w
Richard Henderson <[EMAIL PROTECTED]> writes:
| On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
| > Issue 1.
| > void Foo (char *ptr) {
| > *(volatile char *)ptr;
| > }
| ...
| > char c;
| > *(volatile char *)&c; // can this read be deleted?
| ...
| > void Foo (volatile char *ptr
On Sun, Jul 17, 2005 at 09:18:01AM -0700, Ian Lance Taylor wrote:
> This is PR 22278. DannyB posted a simple, untested, patch here:
> http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
Thanks. I think Danny's patch attacks this too late. The
following patch appears to do the right thing with
Richard Henderson <[EMAIL PROTECTED]> writes:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
As I rea
On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
> Issue 1.
> void Foo (char *ptr) {
> *(volatile char *)ptr;
> }
...
> char c;
> *(volatile char *)&c; // can this read be deleted?
...
> void Foo (volatile char *ptr) {
> *(char *)ptr;
I did see Ian's summary,
http://gcc.gnu.o
Richard Henderson <[EMAIL PROTECTED]> writes:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
Case 1:
Richard Henderson wrote:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
yeah, I can understand that :)
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
I've got no interest in reading a thread with 250 messages wherein
language lawyers battle it out in a no-holds-barred grudge match.
Would someone like to summarize, preferably with a test case that
one side assumes to be miscompiled?
Speaking with the optimizer hat on, we *don't* do much optimiza
Daniel Berlin <[EMAIL PROTECTED]> wrote on 17/07/2005 17:33:17:
> On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
[...]
> > I can't agree with that as is. I would refine it to:
> > Anything that *does* optimizes away visible reads or writes of
> > something marked volatile is bugg
On Sun, 2005-07-17 at 08:18 +0300, Michael Veksler wrote:
>
>
>
> Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> > Daniel Berlin <[EMAIL PROTECTED]> writes:
> >
> > | Anything it sees anything in a statement with volatile, it marks the
> > | statement as volatile, which should stop things f
On Sun, 17 Jul 2005, Gabriel Dos Reis wrote:
> "D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
>
> | | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> |
> | | After many exchanges via private mails and
> | | looking at the various reports related to this issue, it has become
> | | clear to me tha
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| You know, the more this goes on the more I believe we should send
| X3J11 a request for clarification. Perhaps X3J11 has been disbanded,
| so there may be problems. But we should ask.
I don't know whether X3J11 is disbanded. However, at the las
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| | At this point we need:
| | (1) agreement from C and C++ maintainers on access through volatile
| | lvalue
|
| I don't know C++ well enough to say whether the analogous optimization
| is wrong for C++.
C++ has resisted, for two
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
|
| > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
| >
| >Andrew Pinski has declared this to be a bug, but the audit trail
| >isn't clear as to why.
|
| Because the abs is a function
Gabriel Dos Reis writes:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will. Do not lie about your objects, and you will not be screwed over.
> | >
> | > only if the language you're implementing the compi
Daniel Berlin <[EMAIL PROTECTED]> writes:
> > In other words, we're asked to agree that the type of an object
> > changes depending on how it is accessed.
> > For the benefit of readers, only the first sentence of this para is
> > the language of the standard; the rest isn't.
> >
> > That an ob
| From: Daniel Berlin <[EMAIL PROTECTED]>
| On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
| > | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| >
| > | After many exchanges via private mails and
| > | looking at the various reports related to this issue, it has become
| > | clear to
On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
Andrew Pinski has declared this to be a bug, but the audit trail
isn't clear as to why.
Because the abs is a function call, there is only one load and should
be only
one load as
| From: Gabriel Dos Reis <[EMAIL PROTECTED]>
|
| "D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
|
| | | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| |
| | | After many exchanges via private mails and
| | | looking at the various reports related to this issue, it has become
| | | clear to me t
[EMAIL PROTECTED] wrote on 17/07/2005 08:30:26:
> Michael Veksler <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> |
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > | Anything it sees anything in a statement with volatile, it marks
the
> | > | stat
Michael Veksler <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
|
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | Anything it sees anything in a statement with volatile, it marks the
| > | statement as volatile, which should stop things from touching it
| > |
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| If GCC4 causes this much problem with X, I wonder what GCC4 will do to
| the Linux kernel. I understand that Linus generally prefers older
| GCCs to newer ones. It would be great if his preference were only
| superstition.
I do not follo
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | Anything it sees anything in a statement with volatile, it marks the
> | statement as volatile, which should stop things from touching it
> | (anything that *does* optimize something marked volatil
| From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| Daniel Berlin <[EMAIL PROTECTED]> writes:
|
| [...]
|
| | > I think that is urgent.
| | No offense, but everyone thinks the problems that affect them are the
| | most urgent.
|
| miscompilation of KDE was declared urgent; I hope bug affecting code
Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
>
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
>
>Andrew Pinski has declared this to be a bug, but the audit trail
>isn't clear as to why.
>
Maybe because gcc treats -O1 differently from -O2, -O3,
and -Os ? Also, since abs is a (b
On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > I think that is urgent.
> | No offense, but everyone thinks the problems that affect them are the
> | most urgent.
>
> miscompilation of KDE was declared urgent; I hope bug a
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I hope bug affecting code
semantics for X is not just "request for enhancement".
-- Gaby
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is buggy).
great!
| I should note that this will probably
> At this point we need:
> (1) agreement from C and C++ maintainers on access through volatile
> lvalue
> (2) agreement with the middle-end maintainers not to "optimize"
> volatile lvalue expressions
We already don't optimize expressions considered to have "volatile"
operands.
I
On Sat, 2005-07-16 at 21:36 -0400, D. Hugh Redelmeier wrote:
> | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
>
> | After many exchanges via private mails and
> | looking at the various reports related to this issue, it has become
> | clear to me that the interpretations offered to justify why GCC
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
|
| | After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that the interpretations offered to justify why GCC is
| | beha
| From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| After many exchanges via private mails and
| looking at the various reports related to this issue, it has become
| clear to me that the interpretations offered to justify why GCC is
| behaving the way it does seem to go beyond what can be inferred.
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
|
| | The way I see it is that people who designed and wrote the standard
| | offer their view and interpretation of of they wrote and some people
| | are determined to offer a different interpretation
| From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| The way I see it is that people who designed and wrote the standard
| offer their view and interpretation of of they wrote and some people
| are determined to offer a different interpretation so that they can
| claim they are well-founded to apply th
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | You make it sound like the standard is crystal clear on this issue, and
| > | everyone who disagrees with your viewpoint a
Daniel Berlin <[EMAIL PROTECTED]> writes:
| We both know that standards committees are not made up of 1 or 2 people,
| and saying "people who designed and wrote the standard offer their view
| and interpretation of of they wrote " is not useful when they do not
| actually speak for the committee.
On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | You make it sound like the standard is crystal clear on this issue, and
> | everyone who disagrees with your viewpoint are just slimeballs trying to
> | get around the clear wor
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| You make it sound like the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of the standard.
I think you're profondly mistaken in your understa
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > | > Daniel Berlin wrote:
| > | > >>> object volatile).
| > | > >>
| > You don
On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> | > Daniel Berlin wrote:
> | > >>> object volatile).
> | > >>
> You don't make people happier by transmutating their programs into
On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will. Do not lie about your objects, and you will not be screwed over.
> | >
> | > only if the language y
On Sat, 2005-07-16 at 23:23 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | > | There is no point in type qualifiers if they can be simply changed at
> | > | will. Do not lie about your objects, and you will not be screwed over.
> | >
> | > only if the language y
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > Daniel Berlin wrote:
| > >>> object volatile).
| > >>
| > >>
| > >> I don't understand your point. given
| > >> void Foo (char const * a) { *(char *)a = 5; }
| > >> the compiler generates c
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > | There is no point in type qualifiers if they can be simply changed at
| > | will. Do not lie about your objects, and you will not be screwed over.
| >
| > only if the language you're implementing the compiler for says so, no
| > matter what nifty t
Dale Johannesen <[EMAIL PROTECTED]> writes:
| > the type of an object
| > changes depending on how it is accessed.
|
| this also makes nonsense of gcc's implementation of type-based aliasing
| rules.
|
|*((int *)&x) = 3
No. That one is specifically covered by the C and C++ standards
(alt
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| - let's not talk about "restrict"
Oh, it was getting fun :-)
-- Gaby
> | There is no point in type qualifiers if they can be simply changed at
> | will. Do not lie about your objects, and you will not be screwed over.
>
> only if the language you're implementing the compiler for says so, no
> matter what nifty transformation you could have done.
>
Except that n
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >> object volatile).
| >
| > I don't understand your point. given
| > void Foo (char const * a) { *(char *)a = 5; }
| > the compiler generates code to store 5 through the pointer 'a'. It doesn't
turn
| > this into a call to 'abort', because it thin
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
| > Sorry for the very late response. It is actually triggered by the
| > bugzilla entry
| > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
| >
| > The motivating example, abstracted f
On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> Daniel Berlin wrote:
> >>> object volatile).
> >>
> >>
> >> I don't understand your point. given
> >> void Foo (char const * a) { *(char *)a = 5; }
> >> the compiler generates code to store 5 through the pointer 'a'. It
> >> doesn't tu
[I'm just a tourist here. I don't subscribe to the gcc list. I don't
hack on gcc itself. I'm just posting because this bug hits me and
didn't seem to be analyzed correctly. I have participated in the C
standardization process for perhaps 20 years. Now that I look at the
GCC list archives, I se
On Jul 16, 2005, at 10:34 AM, Andrew Haley wrote:
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.
I don't have a standard here, but I will point out that IF this
sentence is
interpreted to mean
the type of an
Daniel Berlin wrote:
>>> object volatile).
>>
>>
>> I don't understand your point. given
>> void Foo (char const * a) { *(char *)a = 5; }
>> the compiler generates code to store 5 through the pointer 'a'. It
>> doesn't turn
>> this into a call to 'abort', because it thinks you're writing to co
> In other words, we're asked to agree that the type of an object
> changes depending on how it is accessed.
> For the benefit of readers, only the first sentence of this para is
> the language of the standard; the rest isn't.
>
> That an object referred to through a volatile pointer must
> "te
D. Hugh Redelmeier writes:
> start of Henry Spencer's comment
>
> 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.3.2.1: when an object
object volatile).
I don't understand your point. given
void Foo (char const * a) { *(char *)a = 5; }
the compiler generates code to store 5 through the pointer 'a'. It doesn't turn
this into a call to 'abort', because it thinks you're writing to const storage.
Is this *always* the cas
Daniel Berlin wrote:
> How does this reasoning not apply to *((char *)a) = 5 where a was
> originally of a const qualified type?
> Or do you think you can only *add* qualifiers, and not remove them?
>
> Because if you allow casting away, then you can't ever trust const to be
> true either, just l
On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
> Sorry for the very late response. It is actually triggered by the
> bugzilla entry
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
>
> The motivating example, abstracted from a misbehaving part of X, is:
> void test (c
Sorry for the very late response. It is actually triggered by the
bugzilla entry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
The motivating example, abstracted from a misbehaving part of X, is:
void test (char *addr) {
*((volatile char *) addr);
}
In
> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:
Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:
>> Still, never mind what the C spec appears to say, optimizing away
>> the cast cannot possibly what the user intended.
Geoffrey> The user might have written a routine which tak
Paul Koning <[EMAIL PROTECTED]> writes:
> Still, never mind what the C spec appears to say, optimizing away the
> cast cannot possibly what the user intended.
The user might have written a routine which takes a 'volatile int *',
with the intent that routine would be used on both regular and
volat
> Dale Johannesen writes:
>> Nathan Sidwell wrote:
>> Also, I wonder about the following example
>>
>> int const avail =
>>
>> int main() {
>> while (*(int *)&avail == Foo ())
>>do_something();
>> return 0;
>> }
>>
>> Seeing through the const-stripping cast is a useful optimization.
>
> It i
On May 5, 2005, at 5:23 AM, Kai Henningsen wrote:
[EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in
<[EMAIL PROTECTED]>:
Mike Stump wrote:
int avail;
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
Ok, so, the question is, should gcc produce code that infinit
[EMAIL PROTECTED] (Kai Henningsen) writes:
| [EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in <[EMAIL PROTECTED]>:
|
| > Mike Stump wrote:
| > > int avail;
| > > int main() {
| > > while (*(volatile int *)&avail == 0)
| > > continue;
| > > return 0;
| > > }
| > >
| > >
| > > Ok, s
> "Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes:
Kai> As a QOI issue, it would be nice if such a situation caused a
Kai> warning ("ignoring volatile cast ..." or something like that).
Kai> It's rather dangerous to have the user believe that this worked
Kai> as intended when it didn't
[EMAIL PROTECTED] (Nathan Sidwell) wrote on 03.05.05 in <[EMAIL PROTECTED]>:
> Mike Stump wrote:
> > int avail;
> > int main() {
> > while (*(volatile int *)&avail == 0)
> > continue;
> > return 0;
> > }
> >
> >
> > Ok, so, the question is, should gcc produce code that infinitely loops,
Dale Johannesen wrote:
Both behaviors are standard-compliant.
I don't think anyone's disagreeing with that. The point is that the
user *requires* a volatile read, but the std *does not* guarantee it.
> Treating a reference as volatile when you don't have to just means
> strictly following the rule
1 - 100 of 117 matches
Mail list logo
