This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix miscompilation in output_constant_def


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]