head 1.3; access; symbols pkgsrc-2026Q1:1.3.0.12 pkgsrc-2026Q1-base:1.3 pkgsrc-2025Q4:1.3.0.10 pkgsrc-2025Q4-base:1.3 pkgsrc-2025Q3:1.3.0.8 pkgsrc-2025Q3-base:1.3 pkgsrc-2025Q2:1.3.0.6 pkgsrc-2025Q2-base:1.3 pkgsrc-2025Q1:1.3.0.4 pkgsrc-2025Q1-base:1.3 pkgsrc-2024Q4:1.3.0.2 pkgsrc-2024Q4-base:1.3 pkgsrc-2024Q3:1.1.0.20 pkgsrc-2024Q3-base:1.1 pkgsrc-2024Q2:1.1.0.18 pkgsrc-2024Q2-base:1.1 pkgsrc-2024Q1:1.1.0.16 pkgsrc-2024Q1-base:1.1 pkgsrc-2023Q4:1.1.0.14 pkgsrc-2023Q4-base:1.1 pkgsrc-2023Q3:1.1.0.12 pkgsrc-2023Q3-base:1.1 pkgsrc-2023Q2:1.1.0.10 pkgsrc-2023Q2-base:1.1 pkgsrc-2023Q1:1.1.0.8 pkgsrc-2023Q1-base:1.1 pkgsrc-2022Q4:1.1.0.6 pkgsrc-2022Q4-base:1.1 pkgsrc-2022Q3:1.1.0.4 pkgsrc-2022Q3-base:1.1 pkgsrc-2022Q2:1.1.0.2 pkgsrc-2022Q2-base:1.1; locks; strict; comment @# @; 1.3 date 2024.12.20.09.29.10; author jperkin; state Exp; branches; next 1.2; commitid D5PzlZraPIPVMdCF; 1.2 date 2024.12.15.03.05.12; author brook; state Exp; branches; next 1.1; commitid 5mJaeN8Ojcm3QxBF; 1.1 date 2022.06.16.15.43.55; author adam; state Exp; branches; next ; commitid L6thP25JAiSPnhID; desc @@ 1.3 log @gcc12: Revert previous. This broke the build on Darwin/aarch64 due to the large patchset that we apply for that platform. As this is the chosen gfortran version for pkgsrc on Darwin it also caused widespread breakage of all fortran packages. This can be resolved after the branch. @ text @$NetBSD: patch-libgcc_config.host,v 1.1 2022/06/16 15:43:55 adam Exp $ This is needed for arm64 to get Out-of-line LSE atomics linked into libgcc. libsupc++ fails to link without this, and for arm to build. --- libgcc/config.host.orig 2021-04-08 04:56:29.805761640 -0700 +++ libgcc/config.host 2022-02-02 04:08:51.653635705 -0800 @@@@ -377,6 +377,7 @@@@ aarch64*-*-netbsd*) extra_parts="$extra_parts crtfastmath.o" tmake_file="${tmake_file} ${cpu_type}/t-aarch64" + tmake_file="${tmake_file} ${cpu_type}/t-lse" tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm" md_unwind_header=aarch64/aarch64-unwind.h ;; @@@@ -463,7 +464,8 @@@@ case ${host} in arm*-*-netbsdelf-*eabi*) tmake_file="${tmake_file} arm/t-netbsd-eabi" - unwind_header=config/arm/unwind-arm.h + # GCC 7 vs NetBSD/eabi -> avoid arm unwinder + #unwind_header=config/arm/unwind-arm.h ;; *) tmake_file="${tmake_file} arm/t-netbsd t-slibgcc-gld-nover" @ 1.2 log @The lang/gcc12, lang/gcc13, and lang/gcc14 fail to build on Darwin 24 (MacOS 15) + Xcode 16. This is a known problem that has been fixed upstream; see https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D116809&data=05%7C02%7Cbrook%40biology.nmsu.edu%7C9ac029bebed94a8c076f08dd19568e63%7Ca3ec87a89fb84158ba8ff11bace1ebaa%7C1%7C0%7C638694581737865288%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DIvQP0mbOte9Pjh3UjtXsSGiQhTontx4GTQHNCFwg6E%3D&reserved=0 and associated patches from 2024-09-24 and 2024-09-27. The basic problem is that the legacy library libgcc_s.1 referenced private symbols in the Apple-provided runtime, which have now been removed by Apple and therefore do not resolve. Those symbols never worked anyway, so there should be no legacy code using them. The upstream solution is to drop support for libgcc_s.1 for new versions of Darwin. @ text @d3 1 a3 31 Part 1: drop legacy library build for macOS >= 14 [PR116809]. This is a mixture of two upstream patches. See https://github.com/gcc-mirror/gcc/blob/master/libgcc/config.host libgcc, Darwin: Drop the legacy library build for macOS >= 15 [PR116809]. We have been building a legacy libgcc_s.1 DSO to support code that was built with older compilers. From macOS 15, the unwinder no longer exports some of the symbols used in that library which (a) cuases bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. PR target/116809 libgcc, Darwin: Don't build legacy libgcc_s.1 on macOS 14 [PR116809] d9cafa0 stopped building libgcc_s.1 on macOS >= 15, in part because that is required to bootstrap the compiler using the macOS 15 SDK. The macOS 15 SDK ships in Xcode 16, which also runs on macOS 14. libgcc_s.1 can no longer be built on macOS 14 using Xcode 16 by the same logic that the previous change disabled it for macOS 15. PR target/116809 Parts 2-3: This is needed for arm64 to get Out-of-line LSE atomics linked into libgcc. d6 3 a8 34 --- libgcc/config.host.orig 2024-06-20 08:08:09.000000000 +0000 +++ libgcc/config.host @@@@ -243,19 +243,25 @@@@ case ${host} in tmake_file="$tmake_file t-slibgcc-darwin" # newer toolsets produce warnings when building for unsupported versions. case ${host} in - *-*-darwin1[89]* | *-*-darwin2* ) - tmake_file="t-darwin-min-8 $tmake_file" + x86_64-*-darwin2[0-2]*) + tmake_file="t-darwin-min-11 t-darwin-libgccs1 $tmake_file" + ;; + *-*-darwin2*) + tmake_file="t-darwin-min-11 $tmake_file" + ;; + *-*-darwin1[89]*) + tmake_file="t-darwin-min-8 t-darwin-libgccs1 $tmake_file" ;; *-*-darwin9* | *-*-darwin1[0-7]*) - tmake_file="t-darwin-min-5 $tmake_file" + tmake_file="t-darwin-min-5 t-darwin-libgccs1 $tmake_file" ;; *-*-darwin[4-8]*) - tmake_file="t-darwin-min-1 $tmake_file" + tmake_file="t-darwin-min-1 t-darwin-libgccs1 $tmake_file" ;; *) # Fall back to configuring for the oldest system known to work with # all archs and the current sources. - tmake_file="t-darwin-min-5 $tmake_file" + tmake_file="t-darwin-min-5 t-darwin-libgccs1 $tmake_file" echo "Warning: libgcc configured to support macOS 10.5" 1>&2 ;; esac @@@@ -412,6 +418,7 @@@@ aarch64*-*-freebsd*) d16 1 a16 1 @@@@ -499,7 +506,8 @@@@ arm*-*-netbsdelf*) @ 1.1 log @gcc12: added version 12.1.0 GCC 12 Caveats An ABI incompatibility between C and C++ when passing or returning by value certain aggregates containing zero width bit-fields has been discovered on various targets. As mentioned in PR102024, since the PR42217 fix in GCC 4.5 the C++ front-end has been removing zero width bit-fields from the internal representation of the aggregates after the layout of those aggregates, but the C front-end kept them, so passing e.g. struct S { float a; int : 0; float b; } or struct T { float c; int : 0; } by value could differ between C and C++. Starting with GCC 12 the C++ front-end no longer removes those bit-fields from the internal representation and per clarified psABI some targets have been changed, so that they either ignore those bit-fields in the argument passing by value decisions in both C and C++, or they always take them into account. x86-64, ARM and AArch64 will always ignore them (so there is a C ABI incompatibility between GCC 11 and earlier with GCC 12 or later), PowerPC64 ELFv2 and S/390 always take them into account (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible with GCC 12 or later, incompatible with GCC 4.5 through GCC 11). RISC-V has changed the handling of these already starting with GCC 10. As the ABI requires, MIPS takes them into account handling function return values so there is a C++ ABI incompatibility with GCC 4.5 through 11. For function arguments on MIPS, refer to the MIPS specific entry. GCC 12 on the above targets will report such incompatibilities as warnings or other diagnostics unless -Wno-psabi is used. C: Computed gotos require a pointer type now. C++: Two non-standard std::pair constructors have been deprecated. These allowed the use of an rvalue and a literal 0 to construct a pair containing a move-only type and a pointer. The nullptr keyword should be used to initialize the pointer member instead of a literal 0, as this is portable to other C++ implementations. The configuration option --enable-libstdcxx-allocator no longer supports the bitmap, mt, and pool arguments. Those configurations had been broken for some time. Fortran: OpenMP code using the omp_lib.h include file can no longer be compiled with -std=f95 but now requires at least -std=f2003. Alternatively, use the omp_lib module, which still supports -std=f95 and is recommended to be used instead in general. OpenMP offloading to Intel MIC has been deprecated and will be removed in a future release. The cr16 target with the cr16-*-* configuration has been obsoleted and will be removed in a future release. The hppa[12]*-*-hpux10* and hppa[12]*-*-hpux11* configurations targeting 32-bit PA-RISC with HP-UX have been obsoleted and will be removed in a future release. The m32c*-*-rtems* configuration has been obsoleted and will be removed in a future release. The support for the m32r-*-linux*, m32rle-*-linux*, m68k*-*-openbsd* and vax-*-openbsd* configurations has been removed. STABS: Support for emitting the STABS debugging format is deprecated and will be removed in the next release. All ports now default to emit DWARF (version 2 or later) debugging info or are obsoleted. The optimization level -Ofast now implies -fno-semantic-interposition. General Improvements Vectorization is enabled at -O2 which is now equivalent to the original -O2 -ftree-vectorize -fvect-cost-model=very-cheap. Note that default vectorizer cost model has been changed which used to behave as -fvect-cost-model=cheap were specified. GCC now supports the ShadowCallStack sanitizer, which can be enabled using the command-line option -fsanitize=shadow-call-stack. This sanitizer currently only works on AArch64 targets and it requires an environment in which all code has been compiled with -ffixed-r18. Its primary initial user is the Linux kernel. @ text @d1 1 a1 1 $NetBSD: patch-libgcc_config.host,v 1.2 2022/02/02 22:07:28 mrg Exp $ d3 31 a33 1 This is needed for arm64 to get Out-of-line LSE atomics linked into libgcc. d36 34 a69 3 --- libgcc/config.host.orig 2021-04-08 04:56:29.805761640 -0700 +++ libgcc/config.host 2022-02-02 04:08:51.653635705 -0800 @@@@ -377,6 +377,7 @@@@ d77 1 a77 1 @@@@ -463,7 +464,8 @@@@ @