RE: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

[David Schwartz]

> "David Schwartz" <davids@xxxxxxxxxxxxx> writes:
>
> > The problem is that '*(volatile unsigned int *)' results in a 'volatile
> > unsigned int'.
>
> No, it doesn't.  Values don't have qualifiers, only objects have.
> Qualifiers on rvalues are meaningless.

Yeah. That's the problem here. The 'volatile' has no object to qualify. You
are essentially lying to the compiler (telling it the pointer points to a
volatile object when it doesn't) and hoping it does the right thing.

Nothing in the standard requires any special behavior for accesses through
volatile-qualified pointers. It only requires special behavior for access to
objects that are in fact volatile.

I think the technically right solution is some mechanism to define an object
(which can be volatile-qualified) that exists at a particular address.
Accessing this object would be accessing a volatile object and you'd get all
the things the standard promises.

An adequate solution would probably be to make 'readl' return a
volatile-qualified unsigned integer. However, I'd have no complaints if GCC
provided stronger volatile guarantees than the C standard does, assuring
that even subsequent casts or other changes still assure the access takes
place where you expect it to. Just the guarantees in the standard get you
only signals and longjmp.

It comes down to just what those guarantees GCC provides actually are.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/