compile error for 990203-1.c

compile error for 990203-1.c

[ibanez]

I'm porting a back-end for gcc.
My back-end crached in the compile test pattern 990203-1.c, and
the error message is

      main.c:7: internal compiler error: in purge_addressof, at
function.c:3423

 for (insn = insns; insn; insn = NEXT_INSN (insn))
    if (INSN_P (insn))
      {
      if (! purge_addressof_1 (&PATTERN (insn), insn,
                         asm_noperands (PATTERN (insn)) > 0, 0, 1, ht))
        /* If we could not replace the ADDRESSOFs in the insn,
           something is wrong.  */
        abort ();
      /* If we find a REG_RETVAL note then the insn is a libcall.
            Such insns must have REG_EQUAL notes as well, in order
            for later passes of the compiler to work.  So it is not
            safe to delete the notes here, and instead we abort.  */

         if (! purge_addressof_1 (&REG_NOTES (insn), NULL_RTX, 0, 0, 0,
ht))
      {
                  /* If we could not replace the ADDRESSOFs in the insn's
notes,
                     we can just remove the offending notes instead.  */
                  rtx note;
                  if(REG_NOTE_KIND (note) == REG_RETVAL)
                        abort ();              <--- die here

      ...

The pattern 990203-1.c is

      int
      f (f)
             float f;
      {
        long long  *ip = (long long  *) &f;
        return (*ip & 0x7ff0000000000000LL ) != 0x7ff0000000000000LL ;
      }


(insn 26 24 27 0 (set (reg:DI 172)
        (reg:DI 172)) 10 {movdi_split} (nil)
    (insn_list:REG_RETVAL 25 (expr_list:REG_EQUAL (and:DI (mem:DI
(addressof:SI (reg/v:SF 169) 166 0x402ade58) [0 S8 A64])
                (const_double 0 [0x0] 2146435072 [0x7ff00000] 0 [0x0] 0
[0x0] 0 [0x0] 0 [0x0]))
            (nil))))

Setting a break point (with cond insn->u.fld[0].rtint == 26) in expression:

      if (! purge_addressof_1 (&REG_NOTES (insn), NULL_RTX, 0, 0, 0, ht))

and use gdb to dump rtl

gdb> p print_rtl(stderr, REG_NOTES(insn))

(insn_list:REG_RETVAL 25
      (expr_list:REG_EQUAL
            (and:DI (mem:DI (addressof:SI (reg/v:SF 169) 166 0x402ade58) [0
S8 A64])
            (const_double 0 [0x0] 2146435072 [0x7ff00000] 0 [0x0] 0 [0x0] 0
[0x0] 0 [0x0]))
        (nil)))$2 = void

which is just the same as the rtl dump.
But the mips back-end get a

 (insn_list:REG_RETVAL 21
       (expr_list:REG_EQUAL
             (and:DI (mem:DI (addressof:SI (mem/f:SF (reg/f:SI 77 $arg) [0
S4 A32]) 182 0x402b5a6c) [0 S8 A64])
                   (const_int 9218868437227405312 [0x7ff0000000000000]))
(nil)))$13 = void

my back-end       ->    (reg/v:SF 169)
mips back-end     ->    (mem/f:SF (reg/f:SI 77 $arg) [0 S4 A32])

It's the mem rtx makes the difference,
but I don't know where the mem rtx comes from.
I have no idea about it.
All those insn notes are generated by gcc
and my back-end knows nothing about it
Any help appreciated.
Thanks

Re: compile error for 990203-1.c

[James E Wilson]

ibanez@sunplus.com wrote:
> It's the mem rtx makes the difference,
> but I don't know where the mem rtx comes from.
> I have no idea about it.

The real question here is why did purge_addressof_1 fail?  You didn't
provide that info.

There are so many different things that could be wrong here that I can
only suggest that you spend some more time debugging your port to figure
out what is going on.  Figure out where the REG_EQUAL note is being
added (try emit_libcall_block or gen_rtx_INSN_LIST).  Check to see if it
was originally a reg or a mem.  If it was originally a reg, figure out
where and why it got changed to a mem.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: compile error for 990203-1.c

[James E Wilson]

ibanez@sunplus.com wrote:
>       main.c:7: internal compiler error: in purge_addressof, at
> function.c:3423

Oh, I forgot to mention, purge_addressof disappeared over a year ago, so
few people are going to care about this.  You are doing a port to
gcc-3.4.x perhaps?  It is important to include info like this, as
porting problems are sometimes version dependent.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com