[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