gcc-9-20190428 is now available
Snapshot gcc-9-20190428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 270633 You'll find: gcc-9-20190428.tar.xzComplete GCC SHA256=6b75ad6fedcc1c4fad77283d440a2816859200d98329949d2eb1397fa590 SHA1=fc3faf9ff892b678dd3caa9657cf255bd1c62fc8 Diffs from 9-20190421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
GCC-9.0.1-RC-20190426 excessive memory usage with -ggdb
While building clang-8.0.0 or firefox-66.0.3 on a gentoo system (x86_64) gcc 9 release candidate runs out of memory with -O2 -ggdb. Gcc 8.3.0 succeeds without issues. For clang there are about 5-6 compilations where the memory usage seems to grow without bound (I have 128Gb RAM + 128Gb swap and at least two of them were observed to reach 80+Gb each before getting killed). For 8.3.0 nothing seems to reach more than single-digit Gb. Without the -ggdb switch gcc 9 also builds fine without excessive memory usage. Files running out of memory: lib/Parse/ParseDeclCXX.cpp lib/Parse/ParseTentative.cpp lib/StaticAnalyzer/Checkers/MallocSizeofChecker.cpp lib/Format/FormatTokenLexer.cpp lib/Format/TokenAnnotator.cpp The assembler output for all but the MallocSizeChecker.cpp was still 0 bytes when the compiler crashed, and it wasn't growing for that one. Experimenting with different -g and -gdwarf levels instead of passing in -ggdb, -g2 -gdwarf-4 crashes, -g2 -gdwarf-3 crashes, -g1 -gdwarf-4 crashes. Both gcc 8.3.0 and 9 were bootstrapped using profiledbootstrap + --with-build-config=bootstrap-lto at -O2. In addition my gcc 9 is currently built with some additional optimization options: ira-loop-pressure, live-range-shrinkage, tree-lrs. I'll try bootstrapping 9 with regular -O2 without pgo/lto and see if that is better. I realize this is a rather low-quality report :) but have little experience in trying to narrow this down esp with cmake being used in clang build, and throwing this out there in case someone else can take a quick look. PS I am not on the list, please include me explicitly on replies.
Re: GCC-9.0.1-RC-20190426 excessive memory usage with -ggdb
On Sun, Apr 28, 2019 at 10:59:45PM -0400, Arvind Sankar wrote: > While building clang-8.0.0 or firefox-66.0.3 on a gentoo system (x86_64) > gcc 9 release candidate runs out of memory with -O2 -ggdb. Gcc 8.3.0 > succeeds without issues. For clang there are about 5-6 compilations > where the memory usage seems to grow without bound (I have 128Gb RAM + > 128Gb swap and at least two of them were observed to reach 80+Gb each > before getting killed). > > For 8.3.0 nothing seems to reach more than single-digit Gb. Without the > -ggdb switch gcc 9 also builds fine without excessive memory usage. > > Files running out of memory: > lib/Parse/ParseDeclCXX.cpp > lib/Parse/ParseTentative.cpp > lib/StaticAnalyzer/Checkers/MallocSizeofChecker.cpp > lib/Format/FormatTokenLexer.cpp > lib/Format/TokenAnnotator.cpp > > The assembler output for all but the MallocSizeChecker.cpp was still 0 > bytes when the compiler crashed, and it wasn't growing for that one. > > Experimenting with different -g and -gdwarf levels instead of passing in > -ggdb, -g2 -gdwarf-4 crashes, -g2 -gdwarf-3 crashes, -g1 -gdwarf-4 > crashes. > > Both gcc 8.3.0 and 9 were bootstrapped using profiledbootstrap + > --with-build-config=bootstrap-lto at -O2. > In addition my gcc 9 is currently built with some additional > optimization options: ira-loop-pressure, live-range-shrinkage, tree-lrs. > > I'll try bootstrapping 9 with regular -O2 without pgo/lto and see if > that is better. > > I realize this is a rather low-quality report :) but have little > experience in trying to narrow this down esp with cmake being used in > clang build, and throwing this out there in case someone else can take a > quick look. > > PS I am not on the list, please include me explicitly on replies. I see this has been reported as Bug 90273 already.