Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX

[Jeff Law <law at redhat dot com>]

Steve Ellcey wrote:
> On Tue, 2008-09-16 at 13:20 -0500, Peter Bergner wrote:
>
>   
> > Would it make more sense to call gen_reg_rtx_and_attrs() and
> > set_reg_attrs_from_value() to get/set the REG_ATTRS and REG_POINTER
> > fields?  There was also a bug (PR36533), where we shouldn't set the
> > REG_POINTER attribute for hard registers.  I'm not sure if that's
> > possible here, but it doesn't seem to be checked.  Using
> > set_reg_attrs_from_value() would protect us from that.
> >
> > Peter
> >     
>
> I think I need to have REG_POINTER set on hard registers.  The failure I
> was getting is:
>
> (insn:TI 1149 1480 1148 45 (set (reg:DI 2 r2 [699])
>         (unspec:DI [
>                 (plus:SI (reg:SI 3 r3 [orig:697 <variable>.object_base ]
> [697])
>                     (reg/v:SI 15 r15 [orig:627 i.69 ] [627]))
>             ] 24)) -1 (nil))
> 20010102-1.c:101: internal compiler error: in get_attr_first_insn, at
> config/ia64/itanium2.md:1838
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> The problem is that neither r3 or r15 are marked as pointers and so I
> don't match my addp4 instruction template.  Does the REG_POINTER
> attribute have to be true or false for the entire life of the hard
> register?  It seems obvious that as different values are put into a hard
> register, sometimes it will have a pointer and sometimes it will not.
>
> I guess I am not sure why setting REG_POINTER on a hard register is bad.
> I looked at PR 36533 but it did not enlighten me.
>   

You don't necessarily need to set REG_POINTER on hard registers, and in 
general it's unwise.

What we do  is we set REG_POINTER on appropriate pseudos within the RTL 
for the pseudo.  Then after register allocation/reloading, alter_reg 
changes the REGNO field for the pseudo to turn it into a hard register.  
Note this preserves the REG_POINTER flag so that you can test it after 
reload. 

So you'll need to look into where that insn was created and ensure that 
the appropriate pseudo has REG_POINTER set (r699)  Then verify that it 
was carried forward through allocation/reloading.

REG_POINTER, when set, indicates the object is a pointer for its entire 
lifetime -- thus setting it on hard registers is generally a bad idea 
and it's only safe under certain circumstances on pseudos, particularly 
in the presence of cross jumping.

jeff