gcc-9-20190428 is now available

2019-04-28 Thread gccadmin
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

2019-04-28 Thread Arvind Sankar
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

2019-04-28 Thread Arvind Sankar
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.