Bug 901750

Summary: gcc internal compiler error in extract_insn, at recog.c:2084 on x86_64
Product: Red Hat Enterprise Linux 5 Reporter: Ondrej Mikle <ondrej.mikle>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Martin Cermak <mcermak>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 5.8CC: law, mcermak, mpolacek, ohudlick
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: https://trac.torproject.org/projects/tor/ticket/7975
Whiteboard:
Fixed In Version: gcc-4.1.2-55.el5 Doc Type: Bug Fix
Doc Text:
Previously, GCC might crash when compiling code with arithmetics on TImode (a sixteen-byte integer) values on x86_64 architecture. The code has been fixed so that the crash does not occur anymore. Note that the 128-bit integer support in 4.1 has several deficiencies; the support is better in gcc44.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-16 00:28:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1049888    
Attachments:
Description Flags
Preprocessed source dumped by gcc upon internal error
none
Script with gcc invocation to trigger the bug
none
Build log when using mock on FC17 with epel-5-x86_64 config none

Description Ondrej Mikle 2013-01-19 00:04:37 UTC
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

Comment 1 Ondrej Mikle 2013-01-19 00:06:20 UTC
Created attachment 682822 [details]
Script with gcc invocation to trigger the bug

This script contains all necessary gcc compilation flags to trigger the bug.

Comment 2 Ondrej Mikle 2013-01-19 00:07:22 UTC
Created attachment 682823 [details]
Build log when using mock on FC17 with epel-5-x86_64 config

Comment 3 Ondrej Mikle 2013-01-19 00:11:16 UTC
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).

Comment 4 Ondrej Mikle 2013-01-19 00:25:43 UTC
Filled out bugzilla fields to match platform as precisely as possible (sorry if this causes too many notifications, this should be last for today).

Comment 5 Jakub Jelinek 2013-03-21 17:01:26 UTC
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.

Comment 6 Jakub Jelinek 2013-03-21 17:54:13 UTC
Ok, seems to be backportable,
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124900
fixes this (the trunk commit was r122945).

Comment 7 Jeff Law 2013-03-21 19:58:26 UTC
Setting to proper component.

Comment 8 RHEL Program Management 2014-01-22 16:32:14 UTC
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.

Comment 10 Dagmar Prokopová 2014-03-25 18:33:06 UTC
Verified for gcc-4.1.2-55.el5.

Comment 13 errata-xmlrpc 2014-09-16 00:28:26 UTC
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