Bug 39076 - internal compiler error when cross-compiling flac
Summary: internal compiler error when cross-compiling flac
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.3.2
: P3 normal
Target Milestone: 4.3.4
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2009-02-02 16:07 UTC by Sven Neumann
Modified: 2009-02-06 01:22 UTC (History)
6 users (show)

See Also:
Host: i486-linux-gnu
Target: arm-linux-uclibcgnueabi
Build:
Known to work: 4.4.0
Known to fail: 4.3.4
Last reconfirmed:


Attachments
preprocessed file that triggers the bug (12.72 KB, text/plain)
2009-02-02 16:08 UTC, Sven Neumann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Neumann 2009-02-02 16:07:10 UTC
I am trying to cross-compile flac 1.2.1 (from http://downloads.sourceforge.net/flac/) for an ARM processor. The toolchain I am using is based on a pretty recent buildroot snapshot (20090130).


Here's the output of gcc -v:

Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with: /home/sven/buildroot/toolchain_build_arm/gcc-4.3.2/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibcgnueabi --enable-languages=c,c++ --with-sysroot=/home/sven/buildroot/build_arm/staging_dir --with-build-time-tools=/home/sven/buildroot/build_arm/staging_dir/usr/arm-linux-uclibcgnueabi/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/sven/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/sven/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --disable-decimal-float --with-float=soft --with-abi=aapcs --with-arch=iwmmxt --with-tune=iwmmxt
Thread model: posix
gcc version 4.3.2 (GCC) 


Here's the command that breaks and the output from the compiler:

/home/sven/buildroot/build_arm/staging_dir/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/home/sven/buildroot/build_arm/staging_dir/include --sysroot=/home/sven/buildroot/build_arm/staging_dir/ -isysroot /home/sven/buildroot/build_arm/staging_dir -mabi=aapcs -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DARM_UNROLL_FIX -DHAVE_CONFIG_H -I. -I. -I../.. -DFLaC__INLINE=__inline__ -DNDEBUG -I../.. -I./include -I../../include -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/usr/include -O3 -funroll-loops -finline-functions -Wall -W -Winline -Os -I/home/sven/buildroot/build_arm/staging_dir/usr/include -I/home/sven/buildroot/build_arm/staging_dir/include --sysroot=/home/sven/buildroot/build_arm/staging_dir/ -isysroot /home/sven/buildroot/build_arm/staging_dir -mabi=aapcs -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DARM_UNROLL_FIX -MT bitreader.lo -MD -MP -MF .deps/bitreader.Tpo -c bitreader.c  -fPIC -DPIC -o .libs/bitreader.o
bitreader.c: In function 'bitreader_read_from_client_':
bitreader.c:288: internal compiler error: Segmentation fault
Comment 1 Sven Neumann 2009-02-02 16:08:26 UTC
Created attachment 17228 [details]
preprocessed file that triggers the bug
Comment 2 Falk Hueffner 2009-02-02 19:02:03 UTC
No problem with the trunk, but it's still there in the 4.3 branch.

Here's a test case. Requires -funroll-loops -Os, no problem with any other -O,  or without -funroll-loops, curiously.

int f(int x, int y) {
    int bytes = 4 * x + y;
    if (bytes == 0)
        return 0;
    return bytes + 1;
}
Comment 3 Sven Neumann 2009-02-03 16:14:20 UTC
The code in flac that triggered the problem does also make gcc crash with "-O3 -funroll-loops". I've also tested -O1 and -O2, same problem.
Comment 4 Ramana Radhakrishnan 2009-02-03 21:43:45 UTC
(In reply to comment #2)


> No problem with the trunk, but it's still there in the 4.3 branch.
> 
> Here's a test case. Requires -funroll-loops -Os, no problem with any other -O, 
> or without -funroll-loops, curiously.
> 
> int f(int x, int y) {
>     int bytes = 4 * x + y;
>     if (bytes == 0)
>         return 0;
>     return bytes + 1;
> }
> 

I get the same problem even with a arm-none-eabi toolchain with the 4.3 branch only. 

For this particular testcase, the ICE is generated in final.c : cleanup_subreg_operands for the alter_subreg call for the following rtx. 
(insn:HI 9 8 17 /home/ramana/test.c:3 (parallel [
            (set (reg:CC_NOOV 24 cc)
                (compare:CC_NOOV (plus:SI (mult:SI (reg:SI 0 r0 [ x ])
                            (const_int 4 [0x4]))
                        (reg:SI 1 r1 [ y ]))
                    (const_int 0 [0x0])))
            (set (reg/v:SI 0 r0 [orig:133 bytes ] [133])
                (plus:SI (cc0)
                    (cc0)))
        ]) 265 {*arith_shiftsi_compare0} (expr_list:REG_DEAD (reg:SI 1 r1 [ y ])
        (nil)))
 
Looking at the dumps this rtx is generated by the rename registers pass in 4.3.x . In trunk however rename registers does not generate this rtx and hence there is no problem. It could still be latent but one has to dig deeper. 
Comment 5 Ramana Radhakrishnan 2009-02-03 22:06:01 UTC
(In reply to comment #4)

> Looking at the dumps this rtx is generated by the rename registers pass in
> 4.3.x . In trunk however rename register does not generate this rtx and hence
> there is no problem. It could still be latent but one has to dig deeper. 

A quick comparison of trunk and gcc 4.3 branch shows the following patch being applied in trunk vs. the 4.3 branch. 

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html

A quick check with the patch at 

ramana@numenor:~/cos/mycos/gcc/gcc$ svn diff -r137128:137235 regrename.c 
Index: regrename.c
===================================================================
--- regrename.c	(revision 137128)
+++ regrename.c	(revision 137235)
@@ -812,7 +812,7 @@
 		    OP_IN, 0);
 
 	  for (i = 0; i < recog_data.n_dups; i++)
-	    *recog_data.dup_loc[i] = copy_rtx (old_dups[i]);
+	    *recog_data.dup_loc[i] = old_dups[i];
 	  for (i = 0; i < n_ops; i++)
 	    *recog_data.operand_loc[i] = old_operands[i];
 	  if (recog_data.n_dups)

Comment 6 Ramana Radhakrishnan 2009-02-04 08:34:14 UTC
(In reply to comment #5)
> (In reply to comment #4)
> 
> > Looking at the dumps this rtx is generated by the rename registers pass in
> > 4.3.x . In trunk however rename register does not generate this rtx and hence
> > there is no problem. It could still be latent but one has to dig deeper. 
> 
> A quick comparison of trunk and gcc 4.3 branch shows the following patch being
> applied in trunk vs. the 4.3 branch. 
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01577.html
> 
> A quick check with the patch at 
> 
> ramana@numenor:~/cos/mycos/gcc/gcc$ svn diff -r137128:137235 regrename.c 
> Index: regrename.c
> ===================================================================
> --- regrename.c (revision 137128)
> +++ regrename.c (revision 137235)
> @@ -812,7 +812,7 @@
>                     OP_IN, 0);
> 
>           for (i = 0; i < recog_data.n_dups; i++)
> -           *recog_data.dup_loc[i] = copy_rtx (old_dups[i]);
> +           *recog_data.dup_loc[i] = old_dups[i];
>           for (i = 0; i < n_ops; i++)
>             *recog_data.operand_loc[i] = old_operands[i];
>           if (recog_data.n_dups)
> 

Related discussions and patch proposed here. 

http://gcc.gnu.org/ml/gcc/2009-02/msg00074.html

This is essentially a backport of a patch in trunk - A full bootstrap and regression test is underway. I've confirmed that this patch fixes the ICE mentioned with the ARM port.

 
Comment 7 Ramana Radhakrishnan 2009-02-04 21:56:42 UTC
(In reply to comment #6)

This has now been committed as revision 143942 in the 4.3 branch - 

Sven, could you check and get back if you still see a problem . If not this bug can be closed 
Comment 8 Sven Neumann 2009-02-05 10:06:32 UTC
I have applied this patch and the problem is gone. Thanks a lot.