Bug 1787575

Summary: g++ 4.8.5 runs out of memory whereas same works with old g++
Product: Red Hat Enterprise Linux 7 Reporter: iyerr
Component: gccAssignee: Marek Polacek <mpolacek>
Status: CLOSED WONTFIX QA Contact: Alexandra Petlanová Hájková <ahajkova>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.5CC: fweimer, jakub, law, ohudlick, sipoyare, thrinath.kondala
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-13 19:25:53 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
Contains data to reproduce the issue. none

Description iyerr 2020-01-03 13:21:11 UTC 
Created attachment 1649417 [details]
Contains data  to reproduce the issue.

Description of problem:
gcc verison 4.8.5-36 runs out of memory whereas same works on old version. Tried on gcc 4.4.7-3.

Version-Release number of selected component (if applicable):
4.8.5-36

How reproducible:
Untar attached tar file and fire below mentioned compile command. On old g++ (4.4.7-3) compilation is successful. On 4.8.5-36, it fails.

Steps to Reproduce:
1. tar zxvf gcc_data.tgz
2. cd gcc_data
3. g++ -march=nocona -mfpmath=sse  -include inclall.h  -o s1823_1.o -shared -O0 -fno-strict-aliasing -fexceptions -fsigned-char -Wno-invalid-offsetof -fpic -fpermissive -DNZDEBUG=0 -DGENCODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DFOR_SPU -I./include s1823_1.cpp

Actual results:

$>> g++ -march=nocona -mfpmath=sse  -include inclall.h  -o s1823_1.o -shared -O0 -fno-strict-aliasing -fexceptions -fsigned-char -Wno-invalid-offsetof -fpic -fpermissive -DNZDEBUG=0 -DGENCODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DFOR_SPU -I./include s1823_1.cpp
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

$>> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)


Expected results:

$>> g++ -march=nocona -mfpmath=sse  -include inclall.h  -o s1823_1.o -shared -O0 -fno-strict-aliasing -fexceptions -fsigned-char -Wno-invalid-offsetof -fpic -fpermissive -DNZDEBUG=0 -DGENCODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DFOR_SPU -I./include s1823_1.cpp
$>> echo $?
0
$>> g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)


Additional info:
Comment 3 Jakub Jelinek 2020-01-08 10:17:17 UTC 
Upstream PR93199 now has a short testcase that reproduces this behavior, plus bisection details on when GCC behavior changed.
Comment 4 thrinath 2020-01-10 06:08:51 UTC 
Hi Team ,may I know the current  status of the bug..
Comment 5 Jakub Jelinek 2020-01-10 08:09:33 UTC 
The upstream PR tracks the current status, once it is done (not the case yet), we can start considering backports, but it will take a while, this isn't something that would have updates issued immediately like important security bugs.
The https://gcc.gnu.org/r246314 might be backportable provided sufficient testing, the other changes from the PR look too risky, but we could instead apply something that is being considered for 9/8 backports, which is punt in sink_clobbers for -O0 (maybe -O1 too) if we would move say more than 4096 clobbers, which would break the quadratic behavior.

I don't know what the generator that generates this kind of code is, but if I could suggest something, one wouldn't run into this behavior if the code used if (...) { ... } else { ... } rather than ?:, because the latter in C++ has the serious disadvantage that all temporaries need to stay around until the whole toplevel statement finishes, which causes those 80000 temporary destruction until the end of the whole statement, rather than destructing each temporary shortly after construction.
Comment 6 Jakub Jelinek 2020-01-10 09:34:33 UTC 
Oh, and forgot to say, easy workaround until this is fixed would be to add -fstack-reuse=named_vars (or -fstack-reuse=none) option for the problematic sources.
Comment 7 Marek Polacek 2020-01-13 19:25:53 UTC 
Not fixable in RHEL 7.  There are proposed workarounds that can mitigate this problem.  Closing out.