[PATCH] Fix miscompilation in output_constant_def
Mark Mitchell
mark@codesourcery.com
Tue Jun 30 09:16:00 GMT 2009
Maxim Kuvyrkov wrote:
> But here we have a TREE_CONSTANT_POOL_ADDRESS entry; the difference
> between the two is that the former is used for function-scope constants
> and the later is used for file-scope constants; the entries between the
> pools do not mix, it is either the one or the other. The second, more
> relevant to us right now difference, is that TREE_CONSTANT_POOL_ADDRESS
> entries are handled exclusively in varasm.c:
>
> /* 1 if RTX is a symbol_ref that addresses a value in the file's
> tree constant pool. This information is private to varasm.c. */
> #define TREE_CONSTANT_POOL_ADDRESS_P(RTX) ...
>
> This can only be achieved by returning copies of memory references.
Yes, it does look like TREE_CONSTANT_POOL_ADDRESS_P applies only to
file-scope constants and is handled entirely within varasm.c. I agree
with your original analysis that something needs to make a copy before
placing the result of a call to output_constant_def into an instruction.
However, I'm not sure whether that copying needs to happen in
output_constant_def, or could happen somewhere later in the process.
What does the call stack look like at the point where the RTX "escapes"
from varasm.c?
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713
More information about the Gcc-patches
mailing list