lang/gcc*: disable building of libssp

For today's FreeBSD 14 and earlier, libssp is a nop because nothing on
FreeBSD will be referencing these headers or lib.  On FreeBSD 15, it
actively breaks building with FORTIFY_SOURCE enabled and it's not worth
trying to make it work- the potential for GCC improvements comes from
the __builtin_object_size enhancement, not from these headers.

PR:		280265
Approved by:	salvadore (maintainer)

lang/gcc13: Update to 13.3.0

Changes: https://gcc.gnu.org/gcc-13/changes.html#13.3

PR:		281091
Tested by:	exp-run (antoine)

lang/gcc13: enable on riscv64

Builds fine on 15-CURRENT.

PR:		272759
Approved by:	salvadore (maintainer)
MFH:		2024Q2

lang/gcc{12,13}: Switch back to standard bootstrap

Switch back to STANDARD_BOOTSTRAP on i386, amd64 and aarch64 as default
option instead of LTO_BOOTSTRAP, forwarding the changes already commited
in the devel ports (commits daf12c76bd531335f58e7602afd3bc8da8fc5c33,
872d61f8ead10a6d935117876cf60057a46770ff, and
da4cb11216a7ed594d5dc453deb4693b48c3c7e9) and in lang/gcc11 (commit
3e0fc5e7607d30400bfb3d5a7b3d1b77e1a6699a)

Users wanting to use LTO_BOOTSTRAP can still enable the option manually.

PR:		273397
Tested by:	exp-run (antoine)

lang/gcc13: Moved man to share/man

Approved by:    portmgr (blanket)

lang/gcc13: Fix Address sanitizer

Software compiled with -fsanitize=address fails to run with the error
message "ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it
with LD_PRELOAD".

This commit fixes the issue by ignoring the [vdso] loaded shared library
instead of linux-vdso.so.

To successfully run the software compiled with -fsanitize=address it is
still necessary to disable ASLR.

PR:		267751
Reported by:	yuri

Co-authored-by:	Andreas Tobler <andreast@gcc.gnu.org>

lang/gcc13: drop ELFv1 support

*/*: Sunset 12.4-RELEASE/12-STABLE from ports tree

- Remove all references to defunct ARCH arm
- Remove all references to defunct ARCH sparc64
- Remove x11-drivers/xf86-video-sunffb which requires defunct sparc64
  ARCH
- Remove sysutils/afbinit requires defunct sparc64 ARCH
- Remove all references to bktr driver
- Remove all references to defunct FreeBSD_12
- Remove all references to OSVERSION/OSREL corresponding to 12
- Remove conditionals in Mk/Uses/cabal.mk
- Remove sparc reference from Mk/Uses/qt-dist.mk
- Remove BROKEN_sparc64/NOT_FOR_ARCH=sparc64
- Remove BROKEN_FreeBSD_12* from:
- Remove OpenSSL patches from:
- Remove conditional flags for OSVERSION >= 1300000 to fixed flags.
  Also move conditional flags for non sparc64/arm ARCH to fixed flags.

Reviewed by:	brooks, jbeich, rene, salvadore
Differential Revision: https://reviews.freebsd.org/D42068

lang/gcc12 lang/gcc12-devel lang/gcc13 lang/gcc13-devel lang/gcc14-devel: fix
build without bootstrap

When more recent gcc ports are built without bootstrap, compiling libcc1
plugins results in errors similar to:

  In file included from
/wrkdirs/share/dim/ports/lang/gcc13/work/gcc-13.2.0/libcc1/libcc1plugin.cc:72:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
  /usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier
    289 |         __status = (unsigned char*)malloc(__nkw);
        |                                    ^
  /usr/include/c++/v1/locale:1584:28: error: attempt to use a poisoned
identifier
   1584 |         __ob =
(char_type*)malloc(2*static_cast<size_t>(__nc)*sizeof(char_type));
        |                            ^

lang/gcc12+: forward the installation of ISO_Fortran_binding.h in a separate dir

PR:		275431
Approved by:	salvadore@ (maintainer)

lang/gcc13: Update to 13.2.0

Changes: https://gcc.gnu.org/gcc-13/changes.html#13.2

lang/gcc13: disable LTO on powerpc to fix build

cc1plus: out of memory allocating 48749344 bytes after a total of 0 bytes

lang/gcc10 lang/gcc11 lang/gcc11-devel lang/gcc12 lang/gcc12-devel lang/gcc13
lang/gcc13-devel lang/gcc14-devel: fix build with libc++ 17

When building relatively recent gcc ports (with C++ in them) against
libc++ 17, you get errors similar to:

  In file included from
/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/cp/module.cc:208:
  In file included from
/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/system.h:239:
  In file included from /usr/include/c++/v1/vector:321:
  In file included from /usr/include/c++/v1/__format/formatter_bool.h:20:
  In file included from /usr/include/c++/v1/__format/formatter_integral.h:32:
  In file included from /usr/include/c++/v1/locale:202:
  /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only
applies to structs, variables, functions, and namespaces
    546 |     _LIBCPP_INLINE_VISIBILITY
        |     ^
  /usr/include/c++/v1/__config:813:37: note: expanded from macro
'_LIBCPP_INLINE_VISIBILITY'

lang/gcc*: fix build with CPUTYPE?=g[3-5]

GCC does not accept -mcpu=g4, but does accept -mcpu=G4.

lang/gcc13: switch to using clang on powerpc64*

As with other released GCC versions (as opposed to snapshots), use base
clang to build this port.

lang/gcc13: Add port

GCC, the GNU Compiler Collection, supports a number of languages.
This port installs the C, C++, and Fortran front ends as gcc13,
g++13, and gfortran13, respectively.

This is the first release from the GCC 13 series.
It largely is a copy of lang/gcc13-devel, with release-specific
modifications from lang/gcc12.

Common issues that could happen when porting code to GCC 13:
https://gcc.gnu.org/gcc-13/porting_to.html

Changes: https://gcc.gnu.org/gcc-13/changes.html

Reviewed by:	gerald, Dan McGregor <dan.mcgregor@usask.ca>
Differential Revision:	https://reviews.freebsd.org/D39841