*/*: Cleanup use of CONFIGURE_TARGET Since 4d1f8f16c1c9 replacing amd64 with x86_64 is not necessary.23544948cb
Port details
lang/gcc13 13.5.0
GNU Compiler Collection 13
Port info
- Maintainer
- salvadore@FreeBSD.org
- Packages
- latest: 13.5.0
- Upstream
- up to date
- Last update
- to 13.5.0 · 23544948cb
- Quarterly
- 2026Q4: 13.3.0_6
- WWW
- https://gcc.gnu.org
- Links
- cgit · VuXML
Install
- Package
# pkg install gcc13installs 13.5.0 fromlatest; fromquarterly(2026Q4) 13.3.0_6- Port
# cd /usr/ports/lang/gcc13 && make install clean# make -C /usr/ports/lang/gcc13 config # change options first
- Size
- 85 MiB download · 322 MiB installed
- Depends on
- devel/binutils 2.44,1, math/gmp 6.3.0, math/mpc 1.4.1, math/mpfr 4.2.2,1, print/indexinfo 0.3.1_1
- License
- GPLv3 and GPLv3RLE
- Options
- 2 of 4 on in the package: MULTILIB STANDARD_BOOTSTRAP
Show the 2 options that are off
GRAPHITE LTO_BOOTSTRAP - pkg-message
Shown after installing
To ensure binaries built with this toolchain find appropriate versions of the necessary run-time libraries, you may want to link using -Wl,-rpath=/usr/local/lib/gcc13 For ports leveraging USE_GCC, USES=compiler, or USES=fortran this happens transparently.
Packages by version and architecture
latest
| FreeBSD version | amd64 | aarch64 | i386 |
|---|---|---|---|
| FreeBSD 16 | 13.5.0 | 13.5.0 | – |
| FreeBSD 15 | 13.5.0 | 13.5.0 | – |
| FreeBSD 14 | 13.5.0 | 13.4.0 | 13.5.0 |
quarterly (2026Q4)
| FreeBSD version | amd64 | aarch64 | i386 |
|---|---|---|---|
| FreeBSD 15 | 13.3.0_6 | 13.3.0_6 | – |
| FreeBSD 14 | 13.3.0_6 | 13.3.0_6 | 13.3.0_6 |
version as in the ports tree (latest) or the most common one (quarterly) · different version · ✗ not built · – no packages for this platform. Package sets that have not been rebuilt for 60 days are left out.
Unaddressed and VuXML only (0)
No unaddressed CVE and nothing reported by
pkg audit for the packaged version 13.5.0.Not counted (1)
CVEs that match this port only loosely: inherited from the whole project, or with versions that cannot be compared. What does this mean?
1 with versions that cannot be compared
The CVE record gives dates or the port uses snapshot versions (or the other way round), so the version of this port cannot be placed in the affected range.
| CVE | CVSS | Published | Description |
|---|---|---|---|
| CVE-2023-4039 | 4.8 | 2023-09-13 | **DISPUTED**A failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamic… |
Fixed (0)
No VuXML entries for this package.
Problem reports (1) · open in Bugzilla, most recently changed first
| PR | Summary | Status | Changed |
|---|---|---|---|
| 278942 | maintainer-feedback+ lang/gcc13: The ieee_arithmetic is missing on the ARM64 architecture | Open | 2024-05-16 |
Commits (27)
lang/gcc13: Update to 13.5.0 Changes: https://gcc.gnu.org/gcc-13/changes.html#13.52564df8375
lang/gcc13: Update to 13.4.0 Also remove files/patch-libgcc-config.host: patch has been upstreamed with upstream commit 4f3a1ef6a8f32e4583d4c67fc452db9aa7fccb68. Patch had been tested in PR 281091 and then forgotten, so I have tested it again more recently before merging it into the main branch (without the full exp-run, it is not needed as GCC 13 is not default GCC version). Changes: https://gcc.gnu.org/gcc-13/changes.html#13.4 PR: 281091 Tested by: exp-run (antoine)81cb874dcc
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/D58116cd7c885d05
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.70f1f8cf77
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: me35a12271a3
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).c02c1227e2
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, jbo6a4bfe6146
gcc*: properly define USE_LDCONFIG32 for multilib13904d7107
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>5d9d9b114e
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: karglf1c61d6af2
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)17024a6f82
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)546dc44194
lang/gcc13: enable on riscv64 Builds fine on 15-CURRENT. PR: 272759 Approved by: salvadore (maintainer) MFH: 2024Q216ebcbbc24
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)41870b7b7dlang/gcc13: Moved man to share/man Approved by: portmgr (blanket)9b0ad9222d
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>11e18f525a
lang/gcc13: drop ELFv1 supportac46ecbfdc
*/*: 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/D42068bbab7f59e9
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));
| ^
This is because gcc's own system.h header poisons these identifiers, and
the libcc1 plugins include <vector> after that. (Note that libstdc++ is
not affected because they seem to have implicitly included <vector>
already at that point.)
Fix it by telling system.h to include <vector> at the correct place, and
removing the explicit includes from libcc1plugin.cc and libcp1plugin.cc.
PR: 275748
MFH: 2023Q4a4831f4933lang/gcc12+: forward the installation of ISO_Fortran_binding.h in a separate dir PR: 275431 Approved by: salvadore@ (maintainer)510dbd1e20
lang/gcc13: Update to 13.2.0 Changes: https://gcc.gnu.org/gcc-13/changes.html#13.23dcacae36f
lang/gcc13: disable LTO on powerpc to fix build cc1plus: out of memory allocating 48749344 bytes after a total of 0 bytesa05177f62a
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'
813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
| ^
/usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI'
792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER))))
| ^
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:547:37: error: expected ';' at end of declaration list
547 | char_type toupper(char_type __c) const
| ^
/usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation
553 | const char_type* toupper(char_type* __low, const char_type* __high) const
| ^
/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here
146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
| ^
This is because gcc/system.h includes safe-ctype.h which redefines ctype
macros such as toupper, tolower, etc to "poison" them.
However, it should only include the safe-ctype.h header *after* any C++
headers, such as <list>, <map>, <string>, etc, otherwise these might
transitively include internal ctype headers (such as with libc++ 17),
causing the above conflicts.
Fix it by moving the safe-ctype.h inclusion to later in gcc/system.h,
which solves this issue, and makes it possible to build against libc++
17.
See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
PR: 274041
Approved by: salvadore (maintainer)
MFH: 2023Q4b7833e78f7lang/gcc*: fix build with CPUTYPE?=g[3-5] GCC does not accept -mcpu=g4, but does accept -mcpu=G4.91117ec83f
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.f4e302c041
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/D39841e14f6cef2c