Bug 901750 - gcc internal compiler error in extract_insn, at recog.c:2084 on x86_64
Summary: gcc internal compiler error in extract_insn, at recog.c:2084 on x86_64
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc
Version: 5.8
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Jakub Jelinek
QA Contact: Martin Cermak
URL: https://trac.torproject.org/projects/...
Depends On:
Blocks: 1049888
TreeView+ depends on / blocked
Reported: 2013-01-19 00:04 UTC by Ondrej Mikle
Modified: 2014-09-16 00:28 UTC (History)
4 users (show)

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.
Clone Of:
Last Closed: 2014-09-16 00:28:26 UTC
Target Upstream Version:

Attachments (Terms of Use)
Preprocessed source dumped by gcc upon internal error (31.67 KB, text/x-csrc)
2013-01-19 00:04 UTC, Ondrej Mikle
no flags Details
Script with gcc invocation to trigger the bug (597 bytes, text/plain)
2013-01-19 00:06 UTC, Ondrej Mikle
no flags Details
Build log when using mock on FC17 with epel-5-x86_64 config (18.29 KB, text/plain)
2013-01-19 00:07 UTC, Ondrej Mikle
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1209 normal SHIPPED_LIVE gcc bug fix update 2014-09-16 04:16:31 UTC

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:

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

+ /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)
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-

Building with `mock --rebuild -r epel-5-x86_64 tor-` 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);

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,
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.


Note You need to log in before you can comment on or make changes to this bug.