This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.3 regression] 20020227-1.c:30: interna compiler error: in


Hi Honza,

> > >Category:       middle-end
> > >Synopsis:       [3.3 regression] 20020227-1.c:30: interna compiler error:
> in reload, at reload1.c:1108 on hppa64-hp-hpux11.11

> > Breakpoint 4, find_reloads (insn=0x800003fffee1c540, replace=0,
> ind_levels=0,
> >     live_known=0, reload_reg_p=0x294) at ../../gcc/gcc/reload.c:2512
> > 2512      rtx set = single_set (insn);
> > (gdb) p debug_rtx (insn)
> > (insn 40 39 41 0 0000000000000000 (set (reg:SF 51 %fr23 [68])
> >         (subreg:SF (reg:DI 20 %r20 [99]) 0)) 121 {*pa.md:3418} (insn_list
> 39 (ni
> > l))
> >     (nil))
> 
> The subreg really looks invalid. It request upper halve of DImode
> register in SFmode format and as such it can not be represented
> I am confused by the support of complex numbers on pa64.  It looks like
> complex SFmode is hold in single integer or floating point register.
> For x86 we always do use two registers avoiding problems here.  Does

Having trouble both with your email jh at suse dot cz and gcc-gnats at gcc dot gnu dot org dot 

The testcase can be simplified to:

typedef __complex__ float cf;
struct x { cf f; } __attribute__ ((__packed__));
void
f2 (struct x *y)
{
  if (y->f)
    abort ();
}

Before reload, we have

(insn 40 39 41 0 0000000000000000 (set (reg:SF 68)
        (subreg:SF (reg:DI 99) 0)) 121 {*pa.md:3418} (insn_list 39 (nil))
    (nil))

(insn 41 40 42 0 0000000000000000 (set (reg:SF 69)
	(subreg:SF (reg:DI 99) 4)) 121 {*pa.md:3418} (nil)
    (expr_list:REG_DEAD (reg:DI 99)
	(nil)))

The SCmode value has been built up byte by byte in reg:DI 99.  After
reload the first run through the reload loop, we have

(insn 66 65 67 0 0000000000000000 (set (mem:SF (plus:DI (reg/f:DI 30 %r30)
                (const_int -144 [0xffffffffffffff70])) [0 S4 A32])
	(subreg:SF (reg:DI 51 %fr23) 0)) -1 (nil)
    (nil))

(insn 67 66 40 0 0000000000000000 (set (reg:SF 50 %fr22 [68])
	(mem:SF (plus:DI (reg/f:DI 30 %r30)
		(const_int -144 [0xffffffffffffff70])) [0 S4 A32])) -1 (nil)
    (nil))

(insn 40 67 68 0 0000000000000000 (set (reg:SF 50 %fr22 [68])
	(reg:SF 50 %fr22 [68])) 121 {*pa.md:3418} (insn_list 39 (nil))
    (nil))

(insn 68 40 69 0 0000000000000000 (set (mem:SF (plus:DI (reg/f:DI 30 %r30)
		(const_int -144 [0xffffffffffffff70])) [0 S4 A32])
	(reg:SF 20 %r20)) -1 (nil)
    (nil))

(insn 69 68 41 0 0000000000000000 (set (reg:SF 52 %fr24)
        (mem:SF (plus:DI (reg/f:DI 30 %r30)
		(const_int -144 [0xffffffffffffff70])) [0 S4 A32])) -1 (nil)
    (nil))

(insn 41 69 42 0 0000000000000000 (set (reg:SF 51 %fr23 [69])
	(reg:SF 52 %fr24)) 121 {*pa.md:3418} (nil)
    (expr_list:REG_DEAD (reg:DI 20 %r20 [99])
	(nil)))

I'm not sure that subregs for insns 40 and 41 before reload are invalid.
I quick hack to try use a pair of general registers for TCmode didn't
seem to change the situation.  So, I don't know how to fix the problem.
The code generated before for this testcase (PR6221) was wrong on
all 64-bit targets except apparently powerpc64.

Isn't the obvious fix to store reg:DI 99 to memory and adjust the memory
address used in the SFmode loads in insns 67 and 69 so that they access
the correct portion of what was in reg 99?

Dave
-- 
J. David Anglin                                  dave dot anglin at nrc-cnrc dot gc dot ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]