This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/12630] [3.4 regression] Various unrecognizable insns and ICEs at -O3
- From: "jh at suse dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Oct 2003 20:33:20 -0000
- Subject: [Bug optimization/12630] [3.4 regression] Various unrecognizable insns and ICEs at -O3
- References: <20031015232442.12630.danglin@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12630
------- Additional Comments From jh at suse dot cz 2003-10-16 20:33 -------
Subject: Re: [3.4 regression] Various unrecognizable insns and ICEs at -O3
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12630
>
>
>
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-10-16 19:59 -------
> Subject: Re: [3.4 regression] Various unrecognizable
>
> > Sorry, I spoke too soon. An ICE occured in stage2:
> >
> > stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/hppa-linux/bin/ -c -g -O2
> > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> > -pedantic -Wno-long-long -Werror -fno-common -DHAVE_CONFIG_H -I. -I.
> > -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include
> > ../../gcc/gcc/varasm.c -o varasm.o
> > ../../gcc/gcc/varasm.c: In function `assemble_real':
> >
> > ../../gcc/gcc/varasm.c:1933: internal compiler error: in schedule_insns, at
> > sched-rgn.c:2744
>
> This may be a gcse bug. We have this rtl after addressof:
>
> (insn 3 161 8 0 ../../gcc/gcc/varasm.c:1902 (set (reg/v/f:SI 94 [ d ])
> (reg:SI 26 %r26 [ d ])) 37 {*pa.md:2265} (nil)
> (nil))
>
> ...
>
> (insn 5 4 6 0 ../../gcc/gcc/varasm.c:1902 (set (reg/f:SI 96 [ d ])
> (reg/v/f:SI 94 [ d ])) 37 {*pa.md:2265} (nil)
> (nil))
>
> (insn 6 5 7 0 ../../gcc/gcc/varasm.c:1902 (parallel [
> (set (mem/s:BLK (reg/f:SI 95) [102 d+0 S24 A32])
> (mem/s:BLK (reg/f:SI 96 [ d ]) [102 d+0 S24 A32]))
> (clobber (reg/f:SI 95))
> (clobber (reg/f:SI 96 [ d ]))
> (clobber (reg:SI 97))
> (clobber (reg:SI 98))
> (clobber (reg:SI 99))
> (use (const_int 24 [0x18]))
> (use (const_int 4 [0x4]))
> ]) 72 {movstrsi_internal} (nil)
> (nil))
>
> After gcse, we have the following insn which doesn't satisfy the constraints:
>
> (insn 6 4 7 0 ../../gcc/gcc/varasm.c:1902 (parallel [
> (set (mem/s:BLK (reg/f:SI 95) [102 d+0 S24 A32])
> (mem/s:BLK (reg/v/f:SI 94 [ d ]) [102 d+0 S24 A32]))
> (clobber (reg/f:SI 95))
> (clobber (reg/f:SI 96 [ d ]))
> (clobber (reg:SI 97))
> (clobber (reg:SI 98))
> (clobber (reg:SI 99))
> (use (const_int 24 [0x18]))
> (use (const_int 4 [0x4]))
> ]) 72 {movstrsi_internal} (nil)
> (nil))
>
> Insn 5 has been deleted.
>
> I don't see any way to have an insn with an operand that's both an input
> and clobbered.
This is not problem - you simply load the value into input operant and
then don't expect it to stay there after the instruction.
The transfromation above looks valid to me. Reload ought to be able to
manage the set operand match clobbers.
(in fact we will likely produce better code if we did clobber
match_scratch with matching operand, like i386 umuldi3_highpart_rex64
does)
Honza
>
> Dave
>
>
>
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.