This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile [was: GCC warnings for unused global variables]
- From: Mike Stump <mrs at apple dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Michael Eager <eager at eagercon dot com>, Fergus Henderson <fjh at cs dot mu dot OZ dot AU>, Geoff Keating <geoffk at geoffk dot org>, jbuck at synopsys dot com, espie at quatramaran dot ens dot fr, gcc at gcc dot gnu dot org
- Date: Wed, 7 May 2003 16:53:00 -0700
- Subject: Re: volatile [was: GCC warnings for unused global variables]
On Wednesday, May 7, 2003, at 04:13 PM, Richard Henderson wrote:
On Wed, May 07, 2003 at 03:58:24PM -0700, Mike Stump wrote:
On Tuesday, May 6, 2003, at 09:03 PM, Alexandre Oliva wrote:
But then, so is a single instruction that loads, operates then
stores,
right? The thing is that GCC doesn't ever give such instruction a
chance if the variable is volatile.
But, obviously, it should be made to.
No, that's not obvious at all.
It means that, the behaviour of the program is going to depend on
(1) Whether the source was written as "i++" or "i += 1" or "i = i +
1".
I think this would be astonishing to most C programmers.
I must not have explained in enough detail what I meant if you thought
I meant that.
I meant something that isn't astonishing. I meant that if the compiler
would generate:
load r0,M
addi r0,1
store r0,M
and if the architecture has:
inc M,1
(defined as load, inc by 1, then store) then the optimizer should be
free to generate:
inc M
if it wants to. Not obligated, not mandated, and not dependent upon
the input form in the source language. This transformation, I claim,
isn't astonishing. I'd claim it is expected (see volatile_okgcc mail
thread from a while ago).
(2) Whether the architecture supports load/op/store instructions at
all.
This reduces portability of driver code across architectures.
Given the difficulty of validating driver code in the first
place, this is surely a big lose.
Nope, don't mean this.
(3) Whether a particular revision of an architecture issues its
load/op/store bus cycles in the same manner. IIRC, 68000 vs
68020 is an example of this sort of change.
If the appearance to the outside world is different enough, then
obviously the other instructions do not match and cannot be used to
replace the first set. Whether this is, or is not the case is port
specific. I don't mean to imply that such issues don't exist.
(4) GCC has never in its history issued load/op/store operations
for volatiles, and changing it now may well break previously
written drivers. This would, in effect, be an ABI change.
I'd be surprised if there were no chips in the set of machines that
would not care about this issue. Imagine a hypothetical machine for a
second that supports load, store, and inc (as above). On this one
machine, I claim (by definition) that the transformation is ok.
Externally, it would appear that the processor fetched the memory, then
wrote to the memory, with the value written would happen to be one
greater than the value loaded.
Are you asserting that on every single CPU that gcc supports that all
of them have different enough behavior to the outside so as to enable
the outside to care? And I mean more than just being able to tell from
timing, timing, we have to agree, can and will change from time to time
and that while this can break drivers, it doesn't break well written
drivers that we care to keep working.
Does x86 for example, how?