[lkml]   [2006]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away
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):

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);

/* 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.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-07 15:05    [W:0.046 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site