This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile semantics
| From: Gabriel Dos Reis <gdr@integrable-solutions.net>
|
| "D. Hugh Redelmeier" <hugh@mimosa.com> writes:
|
| | | From: Gabriel Dos Reis <gdr@integrable-solutions.net>
| |
| | | 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.
| |
| | OK.
| |
| | Is there a consensus on this?
|
| JSM, please chime in.
Maybe Joseph isn't seeing these messages. I've added him to the CC list. For
that reason, I have not trimmed my quotations of your message.
Who wants off the CC list? No fair if you are not subscribed to the
gcc list :-)
I've just now subscribed, so you can drop me from the CC lists.
| | If not, how can a consensus be reached?
|
| try to explain those who read the standard to you their interpretation
| does not match the intent and the letter? Sorry :-)
If I understand what you are saying, I guess the step before is to
have them construct an argument, quoting the standard, that supports
the buggy behaviour (he who frames the question wins :-).
| More seriously, at this point Daniel Berlin has indicated that he gives
| "less of a crap about volatile and optimizing volatile than [he does]
| const, restrict, etc". So that is, I hope, a path to a saner behaviour
| from the code transformation part of the compiler.
|
| | If so, how can we get a fix?
| |
| | I think that is urgent. This bug is causing X to misbehave and the
| | current workarounds might be harmful. Who knows what other
| | manifestations might be lurking?
| |
| | As I said, I'm not a GCC hacker. Who is the likely maintainer to fix
| | this? Does he or she agree that this needs to be done? Urgently?
|
| Joseph S. Myers (jsm at polyomino.org.uk)
Ah, polyominoes. That is one area where I will claim some expertise. For
about 25 years I had enumerated more polyominoes than anyone else.
| and Richard Henderson (rth
| at redhat.com)
I've also added Richard to the CC list.
| are the C front-end maintainers. The following is
| from the last message I received from Joseph (on access through volatile
| lvalue expression):
|
| # Using always the qualification of the lvalue is reasonable semantics to
| # specify (I don't know about to implement). It's still a matter of making
| # a choice and documenting and implementing it.
|
| The issue is compounded by the fact that the code transformation part
| (the "optimizer") is maintained by a different set of people and it takes
| coordination between both worlds to arrive to a useful semantics.
|
| 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++.
| (2) agreement with the middle-end maintainers not to "optimize"
| volatile lvalue expressions
| (3) document the behaviour.
|
| The most important for you and X is to have (2) done, i.e. Richard
| Henderson, Roger Sayle, Daniel Berlin and others.
|
| -- Gaby
As far as (3) is concerned, I think that the combination of the gcc
info node on Volatiles is pretty clear, when read in the context of
Henry's reading of the C standard.
It would be a good idea for everyone to read that node.
To read that node, invoke info:
$ info gcc
Then type:
gVolatiles<enter>
to go to the node "6.2 When is a Volatile Object Accessed?"