This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3 regression] 20020227-1.c:30: interna compiler error: in
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: jh at suse dot cz (Jan Hubicka)
- Cc: dave dot anglin at nrc dot ca, gcc-gnats at gcc dot gnu dot org, jh at suse dot cz, gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Apr 2003 16:32:47 -0400 (EDT)
- Subject: 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)