My apologies for the late response, I've had a lot on my schedule
over the last week.
On Dec 02, 2006, at 23:29:28, David Schwartz wrote:
It comes down to just what those guarantees GCC provides actually
are.
This is the first correct statement in your email. In any case
the documented GCC guarantees have always been much stronger than
you have been trying to persuade us they should be. I would argue
that the C standard somewhat indirectly specifies those guarantees
but I really don't have the heart for any more language-lawyering
so I'm going to leave it at that.
I have tried to find any documentation of the guarantees gcc
actually provides and have been unable to do so. Where are these
"documented GCC guarantees" documented?
Well, under "When is a Volatile Object Accessed" in the GCC manual
(seems to be present for at least a few versions back):
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Volatiles.html#Volatiles
In that case it specifies that any evaluation of "*foo" in an rvalue
context specifies a read (with a few exceptions for G++ where the C++
language generally confuses things). Specifically it mentions the
statement "*src;" and discusses the statement as providing "a void
context". In other words, a statement such as "(void)(expr);" is
redundant because the statement already implies void context and the
extra cast-to-void is just extra text. As such "(void)(*src);" on a
"volatile int *src;" is documented to force a read of "*src". Now,
if you actually _use_ the result over just casting it to void and
discarding it, then GCC can provide no _less_ guarantee with regards
to the read-and-store than it provides to the read-and-discard.
For example:
/* This code is guaranteed to generate assembly to read the memory
address into a register multiple times */
volatile int *foo = (expression);
*foo;
*foo;
/* This code is guaranteed to do the same */
volatile int *foo = (expression);
int x, y;
x = *foo;
y = *foo;
If the result is actually the conditional expression for a loop as in
the problem code then GCC would plainly have no choice about
optimizing, not only is the volatile variable read and returned, but
the result is the conditional for continued execution of a block of
code with unknown side effects.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
