This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix miscompilation in output_constant_def
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Maxim Kuvyrkov <maxim at codesourcery dot com>
- Cc: Jeff Law <law at redhat dot com>, meloun at miracle dot cz, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 29 Jun 2009 19:43:39 -0700
- Subject: Re: [PATCH] Fix miscompilation in output_constant_def
- References: <491DB2C6.7658.C2CA2E3@meloun.miracle.cz> <email@example.com> <492C4A04.firstname.lastname@example.org> <4A4105C6.email@example.com>
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"
(650) 331-3385 x713