Created attachment 682821 [details] Preprocessed source dumped by gcc upon internal error Description of problem: Build with gcc for EL5 x86_64 architecture aborts on "internal compiler error: in extract_insn, at recog.c:2084" upon compilation of djb's NaCl library. Build for i386 seems unaffected. This happens both when building via mock for "epel-5-x86_64" on F17 and also directly on EL5. Both times tried on x86_64 system. Preprocessed source file attached. Using hand-compiled vanilla gcc-4.4.6 on the same system does not exhibit this issue. Version-Release number of selected component (if applicable): gcc.x86_64 4.1.2-52.el5 How reproducible: Always. On FC17 via mock with epel-5-x86_64 config and also directly on EL5. Steps to Reproduce: 1. Download attached preprocessed file EL5-gcc-4.1.2-internal-compiler-error-preprocessed.c and the compiler invocation in run_compile.sh 2. Run ./run_compile.sh on EL5 x86_64 Actual results: Compiler fails with internal error, producing this message after running the run_compile script: {{{ Machine is x86_64 architecture, gcc version is: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =============== + /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I. -I./src/ext -Isrc/ext -I./src/common -Isrc/common -I./src/or -Isrc/or '-DSHARE_DATADIR="/usr/local/share"' '-DLOCALSTATEDIR="/usr/local/var"' '-DBINDIR="/usr/local/bin"' -I./src/common -g -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -MT zzz.o -MD -MP -c -o zzz.o EL5-gcc-4.1.2-internal-compiler-error-preprocessed.c src/ext/curve25519_donna/curve25519-donna-c64.c: In function ‘curve25519_donna’: src/ext/curve25519_donna/curve25519-donna-c64.c:449: error: unrecognizable insn: (insn 10003 10002 10004 20 src/ext/curve25519_donna/curve25519-donna-c64.c:259 (parallel [ (set (reg:CC 17 flags) (unspec:CC [ (reg:DI 2 cx [orig:375 t$0.894 ] [375]) (const_int 2251799813685229 [0x7ffffffffffed]) ] 24)) (set (reg:DI 2 cx [orig:375 t$0.894 ] [375]) (plus:DI (reg:DI 2 cx [orig:375 t$0.894 ] [375]) (const_int 2251799813685229 [0x7ffffffffffed]))) ]) -1 (nil) (nil)) src/ext/curve25519_donna/curve25519-donna-c64.c:449: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccdOxozN.out file, please attach this to your bugreport. + echo Exit code: 1 Exit code: 1 }}} Expected results: Compile results in a working ELF object file. Additional info: Complete src.rpm can be obtained here, if needed: https://people.torproject.org/~hiviah/tor-0.2.4.9.alpha-tor.1.rh5_8.src.rpm Building with `mock --rebuild -r epel-5-x86_64 tor-0.2.4.9.alpha-tor.1.rh5_8.src.rpm` triggers the same bug, as does `./configure --disable-asciidoc && make` on EL5 x86_64 when run on the tar.gz source of unpacked .tar.gz from inside the SRPM (disabling docs generation is just for making it a bit faster). This bug seems very similar, but I'm not sure whether it's identical: https://bugzilla.redhat.com/show_bug.cgi?id=730382 Related error in Tor tracker - https://trac.torproject.org/projects/tor/ticket/7975
Created attachment 682822 [details] Script with gcc invocation to trigger the bug This script contains all necessary gcc compilation flags to trigger the bug.
Created attachment 682823 [details] Build log when using mock on FC17 with epel-5-x86_64 config
Note: EL6 with gcc.x86_64 4.4.6-4.el6 is unaffected by this bug. FC16's and FC17's current gcc versions are unaffected as well. I'd guess some fix would need to be backported (no idea which one).
Filled out bugzilla fields to match platform as precisely as possible (sorry if this causes too many notifications, this should be last for today).
Reduced testcase for -O2: typedef unsigned uint128_t __attribute__ ((mode (TI))); void bar (uint128_t); void foo (uint128_t t[2]) { t[0] += 0x8000000000000 - 1; bar ((t[0] >> 26) | (t[1] << 25)); } I don't think 128-bit integer support in 4.1 is good enough to even try something like that. Anyway, seems the bug went away somewhere in between r122000 and r124000, will bisect to see if the fix might be backportable or not. If not, just use gcc44 to compile code that needs 128-bit integers instead.
Ok, seems to be backportable, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124900 fixes this (the trunk commit was r122945).
Setting to proper component.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Verified for gcc-4.1.2-55.el5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1209.html