This brings a large number of backports (triggered by a Linux vendor's
release), including a dozen of fixes for tree optimizers and other middle
end issues, and nearly as many for the C and C++ front ends, plus some
for i386 and powerpc.
not been addressed upstream yet:
clang on rs6000/powerpc* unfortunately poisons user namespace by default
(without any special options or include files being required).
Until that changes (or GCC changes) we need to avoid using vec_step as a
variable name.
PR: 239266
This brings a fix on the Fortran side and addresses two corner cases
for i386.
On versions of FreeBSD that that are new enough and made that switch
already, use ELFv2 ABI on powerpc64. [1]
PR: 239813 [1]
Submitted by: pkubaj [1]
Reported by: linimon [1]
Backports of a change or two re rs6000 (aka powerpc) and the register
allocator in addition to ones related to PA and SPARC (which we do not
support here).
On the way forward port r499061 | gerald | 2019-04-15 from lang/gcc8 [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]
compile and execute 32-bit binaries with gcc.
The gcc part will be upstreamed as soon as gcc trunk opens for new commits.
On the release front, gcc8, we will merge this commit after a week or so.
Approved by: gerald@
No longer require a not too old version of GCC to build on powerpc64, but
rely on the system compiler (even if that means we need to be explicitly
conservative when it comes to optimizations). [1]
Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there.
PR: 235975 [1]
Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1]
Simplify the creation of the multilib-related sub-directory tree on
powerpc64 and avoid leaving an empty directory behind on the way. [1]
Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there.
PR: 235964, 231804 [1]
Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [1]
which caused the build to fail after the update to binutils 2.31 and was
factually incorrect anyways (the oldest we support being 8548). [1]
On the way update to the 20180201 snapshot of GCC 8.2.1.
PR: 235393 [1]
Reported by: jhibbits [1]
Tested by: jhibbits [1]
