The code from the attachment cause m68k-rtems-gcc to ICE if being compiled with -msoft-float -O2. # m68k-rtems4.7-gcc -O2 -msoft-float -o tmp.o -c paranoia.c paranoia.c: In function 'paranoia': paranoia.c:1238: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. # m68k-rtems4.7-gcc --version m68k-rtems4.7-gcc (GCC) 4.0.0 20050112 (experimental) Optimization levels less than -02 do not trigger the ICE.
Created attachment 7948 [details] Code to reproduce the ICE Sorry for the size of the example (stripped down from RTEMS paranoia.c), but I have not been able to further reduce it.
Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled at -O0.
(In reply to comment #2) > Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled at -O0. Can you reproduce it at -O2?
(In reply to comment #3) > (In reply to comment #2) > > Hmm, I cannot reproduce it on 20050113 with a cross from ppc-darwin compiled > at -O0. > > Can you reproduce it at -O2? No what I had meant is that cc1 was compiled at -O0.
Wierd.. we are on x86-gnu-linux so would be using a totally different host compiler. I am using a gcc 3.4.3 and don't know what Ralf is using. Does it fail when cc1 is compiled at a higher optimization level? Are you saying it looks more like cc1 is being miscompiled on the x86 host?
What options are used to configure gcc, maybe it has something to do with that (what I mean a different default CPU is done). I configured with "../configure --target=m68k-rtems4.7"
(In reply to comment #6) I on Fedora Core 3 and am using FC3's toolchain. > What options are used to configure gcc, maybe it has something to do > with that (what I mean a different default CPU is done). > I configured with "../configure --target=m68k-rtems4.7" /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -v Using built-in specs. Configured with: ../gcc-4.0.0/configure --prefix=/opt/rtems-4.7 --mandir=/opt/rtems-4.7/man --infodir=/opt/rtems-4.7/info --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=m68k-rtems4.7 --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-threads=rtems --enable-languages=c,c++ Thread model: rtems gcc version 4.0.0 20050112 (experimental) I am building gcc one-tree-style with newlib-CVS merged via symlinks into GCC's source-tree.
m68k is not a primary or secondary platform; removing target milestone.
Created attachment 8044 [details] Example 2 to reproduce the ICE There seems to be some improvement on this PR. pr19421.c doesn't trigger the ICE anymore with 4.0.0 as of 20050121. The original code, pr19421.c had been derived from, however still ICEs for certain CFLAGS. I am attaching a somewhat rawer version (pr19421-1.c) of the original code. For me, compiling pr19421-1.c ICEs for # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 -msoft-float pr19421-1.c: In function 'paranoia': pr19421-1.c:2084: internal compiler error: Segmentation fault but doesn't ICE for # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O1 -msoft-float and # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 # m68k-rtems4.7-gcc --version m68k-rtems4.7-gcc (GCC) 4.0.0 20050121 (experimental) Also, this ICE doesn't seem to depend on the version of host compiler being used to compile m68k-rtems4.7-gcc. On FC3, both, a gcc-3.4.2 compiled m68k-rtems4.7-gcc and a gcc4.0.0 compiled m68k-rtems-gcc, expose the same behavior.
Subject: Bug 19421 CVSROOT: /cvs/gcc Module name: gcc Changes by: hubicka@gcc.gnu.org 2005-01-26 08:07:05 Modified files: gcc : ChangeLog tree-inline.c Log message: PR tree-optimization/19421 * tree-inline.c (copy_body_r): Do not walk subtrees after substituting. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7279&r2=2.7280 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-inline.c.diff?cvsroot=gcc&r1=1.168&r2=1.169
Honza, did you add the wrong PR number? I think you mean 19241...
Subject: Re: [4.0/4.1 regression] ICE with soft-float on m68k Why did you turn this from m68k-* to m68k-rtems? It was reported against m68k-rtems but would have be duplicated on at least m68k-elf if not any other m68k target. Even the fix is clearly not RTEMS specific. --joel
(In reply to comment #12) > Subject: Re: [4.0/4.1 regression] ICE with soft-float on > m68k > Why did you turn this from m68k-* to m68k-rtems? > It was reported against m68k-rtems but would have > be duplicated on at least m68k-elf if not any > other m68k target. Even the fix is clearly > not RTEMS specific. Because I could not reproduce it with a cross to m68k-linux-gnu from powerpc- darwin on the mainline.
Not reproducible using x86_64-pc-linux-gnu X m68k-none-elf. I'm using mainline for the cross compiler.
Checking in on this one. Target m68k-rtems4.7 still fails to compile paranoia using 4.0.1 with many patches between 4.0.1 and 4.0.2. Moving to both the head and 4.1 branch as of today, m68k-rtems4.7 compiles paranoia. Any ideas as to what fixed this?
Vanilla 4.0.2 with no further patches applied still fails for me: # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 -msoft-float pr19421-1.c: In function 'paranoia': pr19421-1.c:2084: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Not reproducible with mainiline.