Update to the 20191221 snapshot of GCC 9.2.1.

This brings a larger number of backports (fixes) for Fortran and C++,
but also some for optimizers and the x86 backend. (It pretty much looks
like prep work for a Linux vendor's release, so definitely an important
update.)

Update to the 20191214 snapshot of GCC 9.2.1.

Enable GCC plugins support by default. [1]

PR:		242644 [1]
Submitted by: 	tobik [1]

Update to the 20191207 snapshot of GCC 9.2.1.

Relevant changes include backend work for powerpc (nee rs6000).

Update to the 20191123 snapshot of GCC 9.2.1.

This brings four Fortran and one tree optimizer fixes.

Update to the 20191123 snapshot of GCC 9.2.1.

This addresses a build failure on powerpc ("error: integer constant is
too large for 'long' type"). [1]

It also brings three improvements for both the tree optimizers and middle
end, plus one each for i386 and powerpc, and several on the C++ side.

PR:		241125 [1]

Update to the 20191116 snapshot of GCC 9.2.1.

This brings at least five fixes for the Fortran front end, two corner
cases for i386, and a few for the middle end optimizers.

Forward port r509717 | gerald | 2019-08-24 from lang/gcc9 since this
issue has 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

On versions of FreeBSD that that are new enough and made that switch
already, use ELFv2 ABI on powerpc64.

PR:		239813
Submitted by:	pkubaj
Reported by:	linimon

Backport 517206 | gerald | 2019-11-10 from lang/gcc10-devel:

  Add a new option PLUGINS that enables GCC's plugin framework. This is off
  by default for now, but something to possibly make the default after a bit
  of settling.

  I plan to backport this to lang/gcc9-devel and then lang/gcc9.

Submitted by:	David Carlier <devnexen@gmail.com>
Differential Revision:	https://reviews.freebsd.org/D22292

Update to the 20191109 snapshot of GCC 9.2.1.

This brings an link time optimizer (LTO) fix, four fixes in the Fortran
front end, and a good number of improvements in the C++ front end.

Update to the 20191102 snapshot of GCC 9.2.1.

This brings three backports of bug fixes for Fortran and a few for
code generation across the board (middle end, i386, powerpc).

Update to the 20191026 snapshot of GCC 9.2.1.

This includes a good number of fixes for link-time optimization (LTO)
and tree optimizers, as well as C++ and libstdc++, and some for Fortran.

Update to the 20191019 snapshot of GCC 9.2.1.

This includes four fixes on the Fortran front and a few more around
tree optimizers, debug info,...

Update to the 20191012 snapshot of GCC 9.2.1.

This brings four+ fixes on the Fortran side, one for the C++ front end,
one for rs6000/powerpc (and several for platforms we do not support).

Update to the 20191005 snapshot of GCC 9.2.1.

This mostly fixes (eight) issues on the Fortran side.

Update to the 20190928 snapshot of GCC 9.2.1.

This mainly adds a small change for Arm targets and tones down an error
in C++.

Update to the 20190921 snapshot of GCC 9.2.1.

This brings about half a dozen of fixes on the Fortran front.

Update to the 20190914 snapshot of GCC 9.2.1.

This brings a couple of fixes around Fortran, one two re C++/libstdc++,
plus a bit on the optimization side.

Update to the 20190907 snapshot of GCC 9.2.1.

This brings various backports for the Fortan frontend and the usual
dose of improvements around the house.

Update to the 20190831 snapshot of GCC 9.2.1.

This brings some backports of tree optimization bug fixes, improvements
for rs6000 (aka powerpc), and some for libstdc++.

Update to the 20190824 snapshot of GCC 9.2.1.

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++.

Update to the 20190817 snapshot of GCC 9.2.1.  (This is now past the
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.

Update to the 20180803 snapshot of GCC 9.1.1.

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]

Update to the 20180803 snapshot of GCC 9.1.1.

This brings an assorted number of backports/fixes, pretty much across
the board (and surprisingly many).

Update to the 20180727 snapshot of GCC 9.1.1.

This brings some backports for Fortran, the RTL and tree optimizers,
and a fair number for libstdc++.

Forward port r507388 | gerald | 2019-07-27 from lang/gcc9:

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

Bump PORTREVISION for ports depending on the canonical version of GCC
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

lang/gcc*: Hide pkg-message during upgrades

PR:		239419
Approved by:	gerald (maintainer)

Update to the 20180720 snapshot of GCC 9.1.1.

This brings a number of backports for the C++ front end and a few other
spots.

Update to the 20180713 snapshot of GCC 9.1.1.

This brings some fixes around Fortran, x86-64, tree-based optimizations,...

Update to the 20180706 snapshot of GCC 9.1.1.

Update to the 20180629 snapshot of GCC 9.1.1.

Update to the 20180622 snapshot of GCC 9.1.1.

Update to the 20180615 snapshot of GCC 9.1.1.

Update to the 20180608 snapshot of GCC 9.1.1.

Update to the 20180601 snapshot of GCC 9.1.1.

Update to the 20180525 snapshot of GCC 9.1.1.

Update to the 20180518 snapshot of GCC 9.1.1.

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.

Update to the 20180511 snapshot of GCC 9.1.1.

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.

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

  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

Update to the 20180504 snapshot of GCC 9.1.1, the first snapshot after
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.

Update to the 20180421 snapshot of GCC 9.0.1.

Update to the 20180414 snapshot of GCC 9.0.1.

Update to the 20180407 snapshot of GCC 9.0.1.

Update to the 20180331 snapshot of GCC 9.0.1.

Update to the 20180317 snapshot of GCC 9.0.1.

This commit brings multilib support for gcc on amd64. This means you can
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@

Update to the 20180317 snapshot of GCC 9.0.1.

Update to the 20180310 snapshot of GCC 9.0.1.

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

Update to the 20180303 snapshot of GCC 9.0.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]

Update to the 20190224 snapshot of GCC 9.0.1.

Update to the 20190217 snapshot of GCC 9.0.1.

Update to the 20190210 snapshot of GCC 9.0.1.

Update to the 20190203 snapshot of GCC 9.0.1.

Remove some last traces for powerpcspe support that I missed in r491253. [1]

PR:		235393 [1]

Update to the 20190120 snapshot of GCC 9, now versioned 9.0.1 in
preparation of the release (development stage 4).

Update to the 20190120 snapshot of GCC 9.

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

Update to the 20190113 snapshot of GCC 9.

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]

Update to the 20190106 snapshot of GCC 9.

Install 32-bit libraries for powerpc64 if built.

Approved by:	gerald@

Update to the 20181223 snapshot of GCC 9.

Update to the 20181216 snapshot of GCC 9.

Update to the 20181209 snapshot of GCC 9.

Bump PORTREVISION for ports depending on the canonical version of GCC
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

Update to the 20181202 snapshot of GCC 9.

Update to the 20181125 snapshot of GCC 9.

Create a separate USES block earlier in the Makefile and moving relevant
items there. [1]

Reported by:	portlint [1]

Update to the 20181118 snapshot of GCC 9.

Update to the 20181111 snapshot of GCC 9.

Install texinfo files (GNU info) into ${PREFIX}/share/info

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

Update to the 20181104 snapshot of GCC 9.

Update to the 20181028 snapshot of GCC 9.

Update to the 20181021 snapshot of GCC 9.

Update to the 20181014 snapshot of GCC 9.

Update to the 20181007 snapshot of GCC 9.

Update to the 20180930 snapshot of GCC 9.

This contains a partial fix in the context of PR 231804 that I made
upstream, cf. https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00076.html .

PR:		231804

Update to the 20180923 snapshot of GCC 9.

Update to the 20180916 snapshot of GCC 9.  (The last two weeks' versions
were broken on at least FreeBSD 10/i386 due to a bug that did not trigger
on GNU/Linux systems.)

Forward port r478722 | gerald | 2018-09-01 from lang/gcc7:

Disable the build/use of libssp/gets-chk since FreeBSD 12 and later
do not feature gets() any longer.

(I was planning to make this part of a routine update, alas last week's
snapshot was broken on i386-unknown-freebsd10.x and so will this week's
still.)

PR:		222796, 231066
Differential Revision:	https://reviews.freebsd.org/D12298

Update to the 20180826 snapshot of GCC 9.

Update to the 20180819 snapshot of GCC 9.

Update to the 20180812 snapshot of GCC 9.

Update to the 20180805 snapshot of GCC 9.

Update to the 20180729 snapshot of GCC 9.

Bump PORTREVISION for ports depending on the canonical version of GCC
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.

This includes ports
 - featuring USE_GCC=yes or USE_GCC=any,
 - featuring USES=fortran,
 - using Mk/bsd.octave.mk which in turn features USES=fortran, and those
 - with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
   c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.

PR:		222542

Update to the 20180722 snapshot of GCC 9.

Update to the 20180715 snapshot of GCC 9.

Update to the 20180708 snapshot of GCC 9.

Update to the 20180701 snapshot of GCC 9.

Update to the 20180624 snapshot of GCC 9.

Update to the 20180617 snapshot of GCC 9.

Update to the 20180610 snapshot of GCC 9.

Update to the 20180603 snapshot of GCC 9.

Update to the 20180520 snapshot of GCC 9.

files/patch-libcpp-includenew has now been integrated upstream, so
remove it on our end.

Fix the build on FreeBSD versions with libc++ as default.

The failure mode looked as follows:

  In file included from /scratch/tmp/gerald/gcc-HEAD/libcpp/system.h:442:
  In file included from /usr/include/c++/v1/new:91:
  /usr/include/c++/v1/exception:180:5: error: no member named 'fancy_abort'
  in namespace 'std::__1'; did you mean simply 'fancy_abort'?
      _VSTD::abort();
      ^~~~~~~

Update to the 20180520 snapshot of GCC 9.

Update to the 20180513 snapshot of GCC 9.

Run "/usr/sbin/service ldconfig restart" for USE_LDCONFIG instead of
"ldconfig -m <path>" so the order of ldconfig search directories after
package installation is the same as after a reboot.  The original command
simply appends the path to the list of directories while the ldconfig rc.d
script uses "sort -u".

Bump lang/gcc* which are known to install libraries with exactly the same
name so the library loaded at runtime depends on the order of the search
directories.

PR:		228046
Approved by:	portmgr (antoine)

Update to the 20180506 snapshot of GCC 9.

Now that GCC 8.1 has been released and the GCC 8 branch created, GCC
mainline has become GCC 9 and the 20180429 snapshot of GCC 9.0.0 is
the first of its kind.

Accordingly introduce the gcc9-devel port to track this development
of what ultimately is going to become the GCC 9 release series.