This is the mail archive of the gcc-bugs@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]

[Bug optimization/12630] [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 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.


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