Richard Henderson <[EMAIL PROTECTED]> writes:
> I've got no interest in reading a thread with 250 messages wherein
> language lawyers battle it out in a no-holds-barred grudge match.
> Would someone like to summarize, preferably with a test case that
> one side assumes to be miscompiled?
As I read the messages, quite aside from the language lawyer issues, I
don't think anybody objects to the proposal that using a cast to
volatile should require gcc to do memory accesses as though the
original object were declared to be volatile. (But this change should
not necessarily affect other type qualifiers).
Here is the test case. The proposal is that the two functions should
be compiled to be essentially identical. Currently gcc discards the
memory access in the first function: the 'int *' type of the object
wins over the 'volatile int *' type of the cast.
I happen to have gcc 2.96 (from Red Hat 7.3) and gcc 3.2 installed.
They both act as desired, and do not optimize out the read access.
mainline gcc does optimize out the read access in the first function,
foo.
void
foo (int *p)
{
int i;
i = *(volatile int *) p;
}
void
bar (volatile int *p)
{
int i;
i = *(volatile int *) p;
}
This is PR 22278. DannyB posted a simple, untested, patch here:
http://gcc.gnu.org/ml/gcc/2005-07/msg00699.html
Ian
