This is the mail archive of the
mailing list for the GCC project.
Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- From: Jeff Law <law at redhat dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: luisgpm at linux dot vnet dot ibm dot com, Andrew Pinski <pinskia at gmail dot com>, sje at cup dot hp dot com, Richard Henderson <rth at redhat dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, gcc-patches at gcc dot gnu dot org, paolo dot carlini at oracle dot com
- Date: Thu, 06 Nov 2008 14:31:10 -0700
- Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- References: <firstname.lastname@example.org>
David Edelsohn wrote:
Jeff,Presumably at the point in question we're looking at the lo_sum insn, right?
The RTL is a pair of (high (symbol_ref)) and (lo_sum (reg) (symbol_ref)).
alias.c:find_base_value() has a special case for lo_sum:I think my suggestion will accomplish the same thing -- and it makes
logical sense too -- if we can't determine something from the pointer
reg, then we look at other info, such as the symbol_ref within a lo_sum.
/* The standard form is (lo_sum reg sym) so look only at the
second operand. */
return find_base_value (XEXP (src, 1));
However, find_base_term() throws lo_sum in with PLUS and MINUS,
which prefers the REG. find_base_term() appears to expect that the
symbol_ref from the HIGH will be recorded with the REG and picked
up by the LO_SUM from that source.
find_base_term() either could check for non-zero base before returning
in the lo_sum/plus/minus case statement or could handle lo_sum
explicitly, like find_base_value().