------- Comment #7 from gary at intrepid dot com 2006-05-05 16:58 -------
Consider the following:
volatile int j;
void p()
{
++j;
}
Gimplify in its present form might transform the statement above into
something like the following:
volatile int j;
void p()
{
volatile int T1;
T1 = j + 1;
j = T1;
}
Here, gimplify has created a local temporary but has tagged it as
volatile, because j is volatile.
Taken literally, (j + 1) must be evaluated, and its value stored
into T1, and T1 must be a _memory_ location, not a register,
which looks like this on an x86:
movl j, %eax
addl $1, %eax
movl %eax, -4(%ebp)
movl -4(%ebp), %eax
movl %eax, j
Now as it turns out, somehow gimplify and the follow-on optimization
passes don't seem to target T1 into a memory location, probably because
they "know" that temporary variables for scalars should live in registers.
But still the compiler does create a temporary like T1 above and
qualifies T1 as volatile. The fact that subsequent passes seem to
ignore the qualifier is logically inconsistent, and at some level
incorrect. Will they always ignore that qualifier? Who can say?
Note also that at present "const" and "restricted" (on pointers)
can also be specified. Can't say if applying them to temporaries
causes any real harm, but again, it is logically inconsistent.
If we believe that gimplify should create trees that are well-formed
unambiguous and that precisely describe the semantics of the program
that is being translated, then I think the type qualifiers should be
dropped when declaring compiler temporaries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27445
