FreeBSD source tree https://cgit-dev.freebsd.org/src/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-12-20T19:53:05Z Dimitry Andric dim@FreeBSD.org 2019-12-20T19:53:05Z urn:sha1:0b57cec536236d46e3dba9bd041533462f33dbb7 This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. 2017-03-12T18:59:16Z Warner Losh imp@FreeBSD.org 2017-03-12T18:59:16Z urn:sha1:ffec31518362596811966085741c2d1bec930572 Prefer SRCTOP over CURDIR/../../contrib, etc. However, retain the "up one level" instances of ../ because they are really relative to this part of the tree and not a means to find the root of the tree. As such, it's better to leave them since that further the goal of being able to move directories if watned to in the future. Differential Revision: https://reviews.freebsd.org/D9932 Sponsored by: Netflix Silence On: arch@ (twice) 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 2015-09-25T19:26:08Z Bryan Drewery bdrewery@FreeBSD.org 2015-09-25T19:26:08Z urn:sha1:54c7d75a06d8e6cda90c27c8e722ed2a3c1c20f3 This has not been needed since r284171 in projects/bmake. Sponsored by: EMC / Isilon Storage Division 2015-06-13T19:20:56Z Simon J. Gerraty sjg@FreeBSD.org 2015-06-13T19:20:56Z urn:sha1:ccfb965433c67f3bda935a3cdf334be2e3c4348d Off by default, build behaves normally. WITH_META_MODE we get auto objdir creation, the ability to start build from anywhere in the tree. Still need to add real targets under targets/ to build packages. Differential Revision: D2796 Reviewed by: brooks imp 2014-08-19T06:50:54Z Simon J. Gerraty sjg@FreeBSD.org 2014-08-19T06:50:54Z urn:sha1:ee7b0571c2c18bdec848ed2044223cc88db29bd8 2014-07-07T00:27:09Z Marcel Moolenaar marcel@FreeBSD.org 2014-07-07T00:27:09Z urn:sha1:e7d939bda22b07be6b68ba38835c9167212fd56e This includes: o All directories named *ia64* o All files named *ia64* o All ia64-specific code guarded by __ia64__ o All ia64-specific makefile logic o Mention of ia64 in comments and documentation This excludes: o Everything under contrib/ o Everything under crypto/ o sys/xen/interface o sys/sys/elf_common.h Discussed at: BSDcan 2013-09-05T20:18:59Z Simon J. Gerraty sjg@FreeBSD.org 2013-09-05T20:18:59Z urn:sha1:d1d015864103b253b3fcb2f72a0da5b0cfeb31b6 2013-09-03T17:33:29Z John-Mark Gurney jmg@FreeBSD.org 2013-09-03T17:33:29Z urn:sha1:003f0fa63f779bf3e5c2e43351a5c1dd91a7e627 -maes option, but not the -mpclmul option as I ran out of bits in the 32 bit flags field... You can -D__PCLMUL__ to get this, but it won't be compatible w/ clang and modern gcc... Reviewed by: -current, -toolchain