This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- From: "David Edelsohn" <dje dot gcc at gmail dot com>
- To: "Jeff Law" <law at redhat 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, 6 Nov 2008 17:52:34 -0500
- Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
- References: <303e1d290811061151l43701067pcfb7725fdc73f31c@mail.gmail.com> <4913621E.90508@redhat.com>
On Thu, Nov 6, 2008 at 4:31 PM, Jeff Law <law@redhat.com> wrote:
> Presumably at the point in question we're looking at the lo_sum insn, right?
Yes.
>> 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().
>
> 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.
Yes, it will accomplish the same thing for this particular case.
Currently find_base_value and find_base_term differ in their handling
of LO_SUM. My question is whether this fix should maintain the difference
in algorithms. Also, RTL alias analysis is very fragile and your suggestion
may produce more accurate information in other situations, which could
expose other latent bugs or unexpected behavior.
Luis is going to test both approaches.
Thanks, David