Bug 843923

Summary: GCC internal compiler error: Segmentation fault (program cc1) (ICE) on libopus
Product: [Fedora] Fedora Reporter: Gregory Maxwell <gmaxwell>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: jakub, law
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-17 11:06:23 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:
Attachments:
Description Flags
Input to reproduce the crash none

Description Gregory Maxwell 2012-07-27 16:40:45 UTC 
Created attachment 600831 [details]
Input to reproduce the crash

Description of problem:

GCC ICE while compiling libopus in fixed point.

Libopus is included in fedora, but Fedora only builds it in the floating point configuration.

Version-Release number of selected component (if applicable):
gcc-4.7.0-5.fc17.x86_64

How reproducible:
Completely

Steps to Reproduce:
1. wget http://downloads.xiph.org/releases/opus/opus-0.9.14.tar.gz
2. tar -zxf opus-0.9.14.tar.gz ; cd opus-0.9.14
3. ./configure --enable-fixed-point
4. make
  
Actual results:
gcc: internal compiler error: Segmentation fault (program cc1)

Expected results:
make[1]: Leaving directory `/home/gmaxwell/opus-0.9.14'

Additional info:

Does not happen with gcc-4.6.3-2.fc16.x86_64 (Fedora 16).  Does not happen with O1, does happen with O3. Does not happen with -m32.

I've attached a preprocessed testcase:
gcc -O2 -c preprocessed_test.c -o foo.o
gcc: internal compiler error: Segmentation fault (program cc1)

Does not crash in valgrind, however:
==7172== Invalid read of size 8
==7172==    at 0x9FD128: ??? (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x9FD235: _cpp_clean_line (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xBC3556: ??? (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x9FF0CB: _cpp_lex_direct (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x9FFE1A: _cpp_lex_token (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xA01383: ??? (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x49B92B: preprocess_file (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xA3321B: c_common_init (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xA10F0B: c_objc_common_init (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xAD9534: toplev_main (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x3C35621734: (below main) (libc-start.c:226)
==7172==  Address 0x4d4169f is 155,391 bytes inside a block of size 155,392 alloc'd
==7172==    at 0x4A0892E: realloc (vg_replace_malloc.c:632)
==7172==    by 0xA09C37: xrealloc (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xBC20D0: _cpp_convert_input (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xBC30FA: ??? (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x9FC8E4: _cpp_stack_file (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x7219E3: cpp_read_main_file (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xA32C58: c_common_post_options (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0xAD912C: toplev_main (in /usr/libexec/gcc/x86_64-redhat-linux/4.7.0/cc1)
==7172==    by 0x3C35621734: (below main) (libc-start.c:226)

If I get a chance I'll try to reproduce in GCC trunk, but I haven't built it in a while and I many not get to it soon.
Comment 1 Jakub Jelinek 2012-08-10 07:08:12 UTC 
Can't reproduce, compiles just fine here with the same GCC NVR.