Mainline space problem

[Diego Novillo]

On Fri, 2004-09-03 at 13:40, Bradley Lucier wrote:
> On Sep 3, 2004, at 12:12 AM, James E Wilson wrote:
> 
> > With the attached patch, the may_be_aliased function gives the same
> > result as before for all variables for this testcase.  The testcase can
> > be compiled again, using about 10K pseudos instead of about 130K
> > pseudos.
> 
> Thank you for the patch.  Unfortunately, mainline doesn't bootstrap  
> with or without the patch, with a message of:
> 
> /Users/lucier/programs/gcc/mainline/objdir/gcc/xgcc -shared-libgcc  
> -B/Users/lucier/programs/gcc/mainline/objdir/gcc/ -nostdinc++  
> -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
> libstdc++-v3/src  
> -L/Users/lucier/programs/gcc/mainline/objdir/powerpc-apple-darwin7.5.0/ 
> libstdc++-v3/src/.libs  
> -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/bin/  
> -B/pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/lib/ -isystem  
> /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/include -isystem  
> /pkgs/gcc-mainline/powerpc-apple-darwin7.5.0/sys-include  
> -DHAVE_CONFIG_H -I. -I../../../libjava -I./include -I./gcj  
> -I../../../libjava -Iinclude -I../../../libjava/include  
> -I../../../libjava/../boehm-gc/include -I../boehm-gc/include  
> -I../../../libjava/libltdl -I../../../libjava/libltdl  
> -I../../../libjava/.././libjava/../gcc -I../../../libjava/../zlib  
> -I../../../libjava/../libffi/include -I../libffi/include -O2 -g -O2  
> -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum  
> -D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -Wextra -Wall -D_GNU_SOURCE  
> -DPREFIX=\"/pkgs/gcc-mainline\" -DLIBDIR=\"/pkgs/gcc-mainline/lib\"  
> -DBOOT_CLASS_PATH=\"/pkgs/gcc-mainline/share/java/libgcj-3.5.0.jar\"  
> -DJAVA_EXT_DIRS=\"/pkgs/gcc-mainline/share/java/ext\" -g -O2 -MT  
> interpret.lo -MD -MP -MF .deps/interpret.Tpo -c  
> ../../../libjava/interpret.cc  -fno-common -DPIC -o .libs/interpret.o
> [address=ffffff9d pc=003dd7e8]
> ../../../libjava/interpret.cc: In member function `void  
> _Jv_InterpMethod::run(void*, ffi_raw*)':
> ../../../libjava/interpret.cc:3220: internal compiler error:  
> Segmentation Fault
> 
Yes.  I ran into this one this morning.  What I observed was that:

(gdb) bt
#0  may_trap_p (x=0xffffff9d)
    at gcc/rtlanal.c:2311
#1  0x102605a4 in try_split (pat=Variable "pat" is not available.)
    at gcc/emit-rtl.c:3329
#2  0x103a93d4 in split_insn (insn=0x4114f3c0)
    at gcc/recog.c:2645
#3  0x103a957c in split_all_insns (upd_life=0)
    at gcc/recog.c:2723
#4  0x10428098 in rest_of_handle_flow2 ()

(gdb) l
3329                  if (CALL_P (insn)
3330                      || (flag_non_call_exceptions
3331                          && may_trap_p (PATTERN (insn))))

(gdb) pr insn
(note 9158 0 0 NOTE_INSN_DELETED)

I'm not quite sure when this was introduced as my ppc box had been off
for a couple of days.


Diego.