This includes a Fortran fix related to modules, an optimizer fix re
nested functions, fixes for aarch64 and rs6000 (aka powerpc) and a
few for libstdc++.
GCC 9.2 release, thus the move from 9.1.1 to 9.2.1.)
This brings fixes to register allocation and tree optimizations, LTO,
C++, and a good dose of Fortran.
This brings a larger number of backports for the testsuite, a fix for
Fortran, one for rs6000 (aka powerpc*) and most importantly now longer
has _GNU_SOURCE defined on powerpc64 (which was a regression from the
GCC 8 series [1]).
PR: 239648 [1]
Explicitly depend on GCC 8 (instead of USE_GCC=yes) for powerpc64 to
avoid a dependency loop now that GCC_DEFAULT defaults to GCC 9.
PR: 238330
Reported by: pkubaj
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Proactively add a CONFLICTS statement with the lang/gcc9 port that
should be landing any day now. That'll avoid a PORTREVISION bump
and rebuild at that point.
andreast@ has pushed files/patch-amd64-gcc-multilib-support upstream
after the GCC 9.1 release, so this is now on the GCC 9 branch and can
be removed from our tree.
the release of GCC 9.1 (which is in turn the first in that release series).
Last weeks's snapshot actually was still coming from trunk and contained
early development of what is going to become GCC 10 later on, so we skipped
that one.
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@
Forward port r469788 from lang/gcc6 since apparently people are still using
the -mretpoline option that is specific to clang, and gcc9-devel is going
to branch into gcc9 in a rew months and that one later the default version
of GCC in use:
Filter the -mretpoline command-line option, which is understood by
recent versions of clang (and used in the context of the Spectre
security issues), but not GCC (which uses different options for the
same) from CFLAGS and CXXFLAGS.
This avoids the build of this port via bootstrap, which is the default
and leverages both the system compiler (clang in most cases) plus a just
built version GCC, to fail due to the latter not knowing -mretpoline.
PR: 228205
Submitted by: rozhuk.im@gmail.com
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]
Support for powerpcspe has been removed from upstream GCC in preparation
of the GCC 9 release, so adjust ONLY_FOR_ARCHS and remove our local patch
files/patch-spe-config that we still carry until lang/gcc8 and gcc8-devel.
PR: 234419
Merge r479405 | mat | 2018-09-10 from lang/gcc8-devel to lang/gcc9-devel
as well: [1]
After an include, PLIST_SUB must be appended to, not overwritten.
If it is overwritten, many values will be clobbered, and
pain will ensue.
PR: 230864 [1]
Reviewed by: mat [1]
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
After a discussion on the mailing list on moving manpages to
${PREFIX}/share/man for consistency with base where it is
installed in usr/share/man, it appeared the same should happen
to GNU info files which were installed under share in base and
not in ports.
Now texinfo is not in base on any of the supported version of FreeBSD
it is possible to proceed to this move and it is easier to do than
the manpage change.
Other benefit than consistency are less patching: all build tools but
cmake are expecting info files to be under share/info and cmake (patched here)
was having an exception for BSD so the patch makes FreeBSD case less
specific for them
Bump revision of all impacted ports
PR: 232907
exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D17816
