FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-02-29T03:25:51Z 2020-02-29T03:25:51Z Ed Maste emaste@FreeBSD.org 2020-02-29T03:25:51Z urn:sha1:57f804675e65951d630a38d94c07be4a27ae4053 As described in Warner's email message[1] to the FreeBSD-arch mailing list we have reached GCC 4.2.1's retirement date. At this time all supported architectures either use in-tree Clang, or rely on external toolchain (i.e., a contemporary GCC version from ports). GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later that year, in r171825. GCC has served us well, but version 4.2.1 is obsolete and not used by default on any architecture in FreeBSD. It does not support modern C and does not support arm64 or RISC-V. Thanks to everyone responsible for maintaining, updating, and testing GCC in the FreeBSD base system over the years. So long, and thanks for all the fish. [1] https://lists.freebsd.org/pipermail/freebsd-arch/2020-January/019823.html PR: 228919 Reviewed by: brooks, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D23124 2019-06-25T02:35:22Z Justin Hibbits jhibbits@FreeBSD.org 2019-06-25T02:35:22Z urn:sha1:e861dab451869582008237a8c11e97348d2440ce Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well. The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT. Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598 2018-10-19T00:37:47Z Glen Barber gjb@FreeBSD.org 2018-10-19T00:37:47Z urn:sha1:b958317950db889c01b5fda1a7feb1202c31760e - Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER, FREEBSD_CC_VERSION, OS_VERSION. - Update comment in UPDATING regarding debugging options. - Remove debug.witness.trace=0 from installation media. - Bump __FreeBSD_version. Approved by: re (implicit) Sponsored by: The FreeBSD Foundation 2018-06-27T19:29:15Z Bryan Drewery bdrewery@FreeBSD.org 2018-06-27T19:29:15Z urn:sha1:96a0acc4ce1cbac643c51d118db1912dd63f6bb8 MFC after: 2 weeks Sponsored by: Dell EMC 2018-06-27T18:14:33Z John Baldwin jhb@FreeBSD.org 2018-06-27T18:14:33Z urn:sha1:104f6a2dcdde64f316849b60a428066aaa73cc9c - Change the C++ directory entries to honor --sysroot if it is set. - Don't define CROSS_INCLUDE_DIR for the cross compiler. Instead, set TARGET_SYSTEM_ROOT to point to WORLDTMP and always define STANDARD_INCLUDE_DIR. - Change STANDARD_INCLUDE_DIR and the C++ include directories to just start with "/usr" always. The compiler will prepend the sysroot when doing cross-builds. GCC_INCLUDE_DIR (which contains headers that ship with the compiler such as intrinsincs rather than OS-supplied headers) remains hardcoded to look in TOOLS_PREFIX. Reviewed by: bdrewery (older version) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D15127 2018-06-27T18:11:47Z John Baldwin jhb@FreeBSD.org 2018-06-27T18:11:47Z urn:sha1:7cdb6a830526fb77fc1270c34145d512e3269812 GCC 4.2 prefixes these directories with --sysroot meaning that during buildworld they have a double sysroot. Reviewed by: bdrewery Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14780 2017-10-31T19:02:05Z Bryan Drewery bdrewery@FreeBSD.org 2017-10-31T19:02:05Z urn:sha1:7cd84b56411ceebd98e5972320100c3e9b206956 It merely wanted to use 'all' rather than 'build-tools' so just add a build-tools target to the Makefile. MFC after: 2 weeks Sponsored by: Dell EMC Isilon 2017-10-31T00:07:04Z Bryan Drewery bdrewery@FreeBSD.org 2017-10-31T00:07:04Z urn:sha1:ea825d02749f382c3f7e17f28247f20a48733eab Sponsored by: Dell EMC Isilon 2017-02-01T05:24:17Z Ed Maste emaste@FreeBSD.org 2017-02-01T05:24:17Z urn:sha1:4b1be206bbd705b7795338629b5a55d06aa46b55 Reported by: lidl MFC after: 1 month MFC with: r312899 Sponsored by: The FreeBSD Foundation 2016-10-22T01:57:15Z Justin Hibbits jhibbits@FreeBSD.org 2016-10-22T01:57:15Z urn:sha1:dc9b124d6668d984b8a012e21fef6a0fe585faef Summary: The Freescale e500v2 PowerPC core does not use a standard FPU. Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this. Additionaly, the SPE opcodes overlap with Altivec, so these are mutually exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was created with the same function set as in powerpc/powerpc/altivec.c, so it becomes effectively a drop-in replacement. setjmp/longjmp were modified to save the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by the SPE). Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not support double-precision floating point. Also, without a new MACHINE_ARCH it would be impossible to provide binary packages which utilize the SPE. Additionally, no work has been done to support ports, work is needed for this. This also means no newer gcc can yet be used. However, gcc's powerpc support has been refactored which would make adding a powerpcspe-freebsd target very easy. Test Plan: This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222 (P1022-based) board, compiled against the new ABI. Base system utilities (/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot multiuser. Reviewed By: bdrewery, imp Relnotes: yes Differential Revision: https://reviews.freebsd.org/D5683