13:29 gerald 

Update to the 20191110 snapshot of GCC 10.0.0.

 

23:25 gerald 

Update to the 20191103 snapshot of GCC 10.0.0.

 

07:13 gerald 

Update to the 20191027 snapshot of GCC 10.0.0.

 

05:38 gerald 

Update to the 20191020 snapshot of GCC 10.0.0.

 

16:43 gerald 

Update to the 20191013 snapshot of GCC 10.0.0.

 

04:12 gerald 

Update to the 20191006 snapshot of GCC 10.0.0.

 

00:04 gerald 

Update to the 20190929 snapshot of GCC 10.0.0.

 

14:22 gerald 

Update to the 20190922 snapshot of GCC 10.0.0.

files/patch-pr240387 is part of that snapshot, so remove it on our end.

PR:	240387

 

03:54 gerald 

Update to the 20190915 snapshot of GCC 10.0.0.

 

11:09 gerald 

Update to the 20190908 snapshot of GCC 10.0.0.

This may (or may not) address a build regression (with clang) that
dim@ reported. [1]

PR:		240387 [1]

 

11:18 gerald 

Update to the 20190901 snapshot of GCC 10.0.0.

 

04:37 gerald 

Update to the 201900825 snapshot of GCC 10.0.0.

 

16:30 gerald 

Update to the 201900818 snapshot of GCC 10.0.0.

 

07:08 gerald 

Update to the 201900811 snapshot of GCC 10.0.0.

This no longer has _GNU_SOURCE defined on powerpc64 (which was a
regression from the GCC 8 series). [1]

PR:		239648 [1]

 

17:01 gerald 

Update to the 201900804 snapshot of GCC 10.0.0.

 

13:00 gerald 

Update to the 201900728 snapshot of GCC 10.0.0.

 

17:35 gerald 

Update to the 201900721 snapshot of GCC 10.0.0.

 

06:19 gerald 

Update to the 201900714 snapshot of GCC 10.0.0.

 

15:50 gerald 

Update to the 201900707 snapshot of GCC 10.0.0.

 

21:30 gerald 

Update to the 20190630 snapshot of GCC 10.0.0.

 

08:01 gerald 

Update to the 20190623 snapshot of GCC 10.0.0.

 

16:14 gerald 

Update to the 20190616 snapshot of GCC 10.0.0.

 

05:53 gerald 

Update to the 20190609 snapshot of GCC 10.0.0.

 

21:17 gerald 

Update to the 20190602 snapshot of GCC 10.0.0.

 

23:03 gerald 

Update to the 20190526 snapshot of GCC 10.0.0.

 

18:23 gerald 

Update to the 20190519 snapshot of GCC 10.0.0.

 

10:02 gerald 

Update to the 20190512 snapshot of GCC 10.0.0.  This brings a new binary
bin/lto-dump which may be helpful if you employ link-time optimization (LTO).

Forward port r499061 | gerald | 2019-04-15 from lang/gcc8 and gcc8-devel [1]:

  GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
  the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
  same functions but they also each have their unique functions.  When
  GCC links programs and libraries there are three possibilities:

  1. gcc -static-libgcc or gcc -static: -lgcc
     => Just use libgcc.a.

  2. gcc -shared-libgcc: -lgcc_s -lgcc
     => Link with libgcc_s first, so libgcc.a is only used for its unique
        functions.

  3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
     => Link with libgcc.a first so libgcc_s is only used for its unique
        functions (_Unwind_* functions).

  Approach 3 is the default for gcc and it's also what clang and clang++ use;
  approach 2 is the default for gfortran, g++ and probably other front ends.

  This patch makes 3 the default for gfortran.  It significantly reduces
  the use of libgcc_s.  The _Unwind_* functions are also available in the
  old base system libgcc_s which means this reduces the need for
  -rpath /usr/local/lib/gccN in ports that depend on libraries built with
  gfortran.  Consider a dependency tree like this:

    prog -> libA -> libgcc_s (old base system libgcc_s is fine)
         -> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)

  Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
  a normal C program compiled with clang.  Without -rpath it will fail to
  start because it loads old libgcc_s first as a dependency of libA and then
  it fails to load libB.  With this patch libB works with old base system
  libgcc_s or may not need libgcc_s at all, so prog does not need to be
  linked with -rpath.

PR:		208120 [1]
Submitted by:	tijl [1]

 

21:15 gerald 

Welcome GCC 10, even if only in form of its first development snapshot
at the beginning of what likely is going to be another one year cycle.

files/patch-amd64-gcc-multilib-support has made it upstream after the
creation of the GCC 9 release branch, so we can drop it.