From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE29A3894411; Wed, 28 Apr 2021 00:29:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE29A3894411 From: "vincent.lextrait at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/100299] New: cc1plus taking all RAM Date: Wed, 28 Apr 2021 00:29:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vincent.lextrait at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 00:29:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100299 Bug ID: 100299 Summary: cc1plus taking all RAM Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vincent.lextrait at gmail dot com Target Milestone: --- Created attachment 50692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D50692&action=3Dedit ii file to reproduce the issue. gunzip first. While compiling a relatively large file (ii file ~2 MB), g++ compilation in= -O3 aborts after suddenly allocating in a few steps within a few seconds all the RAM (128 GB!). Compiles just fine with -O2 (and it takes 5 times longer than to abort in -= O3). To my utter surprise, it compiles with -O2 -fgcse-after-reload -fipa-cp-clo= ne -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops -fsplit-paths -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model -fvect-cost-model=3Ddynamic -fversion-loops-for-strides While the specific 11.1 man specifies that these options are equivalent to = -O3. Excerpt of man: -O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the following optimization flags: -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops -fsplit-paths -ftree-loop-distribution -ftree-loop-vectorize -ftree-partial-pre -ftree-slp-vectorize -funswitch-loops -fvect-cost-model -fvect-cost-model=3Ddynamic -fversion-loops-for-strides The man must not be correct, some other option must be added in -O3. I am on x86_64-linux-gnu (Ubuntu 20.04) - but I am fairly sure it is not platform-dependent. gcc is configured using=20 ./configure -v --build=3Dx86_64-linux-gnu --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu --prefix=3D/usr/local/gcc-11.1 --enable-checking=3Drelease --enable-languages=3Dc,c++ --disable-multilib --program-suffix=3D-11.1 The complete command line that triggers the bug: g++-11.1 -std=3Dc++20 -O3 -c test.ii The error: g++-11.1: fatal error: Killed signal terminated program cc1plus compilation terminated. gzipped test.ii attached to this bug report. Previous versions of gcc do not exhibit the bug, but do compile very very slowly compared to -O0 option, or compared to clang.=