lang/gcc1?: further improvements for powerpc64*

1. Backport of e8385ea3b57862ce6c6ace5e6973b96cf238f4b6. Fixes libgcc
on powerpc64*, found with octave crashing.
2. Merge https://gcc.gnu.org/pipermail/gcc-patches/2026-July/723975.html,
not yet upstreamed, but allows to build all the remaining failing ports
due to ld128 switch for powerpc64le.

Differential Revision:	https://reviews.freebsd.org/D58116

lang/gcc1[2-6]: actually fix build on powerpc64le/CURRENT

Without this patch, gcc attempts to enable support for IBM long double,
when IEEE long double is enabled, which is wrong. Allow to only
specify IEEE long double.

The whole patchset for IEEE long double on FreeBSD/powerpc64le
is being upstreamed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126012.

lang/gcc1[2-6]: add necessary contents to patch-gcc_configure

1. For gcc14, restore the lost content.
2. For others, add powerpc64le-related content.

Pointy hat:	me

lang/gcc1?: fix runtime on powerpc64le/CURRENT

Since powerpc64le recently switched to 128-bit long double, use them to
generate proper binaries. Patches are necessary to allow use of
--with-long-double-format=ieee on FreeBSD (to be upstreamed).

lang/gcc13: Fix SIGBUS depending on CPUTYPE

Compiling GCC with some CPUTYPE values (e.g. broadwell) result in
breaking some applications (e.g. math/octave, cad/freecad), sending
a SIGBUS.

The issue is due to GCC generating instructions that require variables
to be aligned in memory on certain CPUs. Our libthr does not have the
required alignment so these CPUs fail to execute these instructions.

The patch disables the generation of such instructions and will get
obsolete once all supported FreeBSD releases include commit
22e564c74eb20e14bd93fd9fdde20e38a29cfcf1.

PR:             285711
Reported by:    cracauer
Tested by:      cracauer, jbo

gcc*: properly define USE_LDCONFIG32 for multilib

lang/gcc13: Fix libisl.so linking

Fix linking with libisl.so depending on GRAPHITE option, which is now
implemented through options helpers.

Co-authored-by: Gerald Pfeifer <gerald@FreeBSD.org>

PR:             276070
Reported by:    Ivan Rozhuk <rozhuk.im@gmail.com>

lang/gcc13: Fix segfaults for static binaries

Fix segmentation faults caused by -static flag into compiled
binaries.

Email thread:
https://lists.freebsd.org/archives/freebsd-hackers/2025-January/004236.html
Upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685

PR:             284441
Reported by:    kargl

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