libcompiler_rt: stop building with stack smashing protectionlibcompiler_rt implements certain functions that clang and gcc emitcalls to as part of their codegen (e.g. for extended width math). Bu
libcompiler_rt: stop building with stack smashing protectionlibcompiler_rt implements certain functions that clang and gcc emitcalls to as part of their codegen (e.g. for extended width math). Buildit without stack smashing protection (SSP, -fstack-protector) in orderto support building binaries without SSP, especially the dynamic linker.Besides, SSP is probably not very valuable in this library.Reviewed by: arichardson, dim, kibSponsored by: Dell EMC IsilonDifferential Revision: https://reviews.freebsd.org/D27786
show more ...
Follow-up r364753 by only using arm's stdatomic.c implementation, as italready covers the functions in compiler-rt's atomic.c, leading toconflicts when linking.PR: 230888MFC after: 3 daysX-MFC
Follow-up r364753 by only using arm's stdatomic.c implementation, as italready covers the functions in compiler-rt's atomic.c, leading toconflicts when linking.PR: 230888MFC after: 3 daysX-MFC-With: r364753
Follow-up r364753 by enabling compiler-rt's atomic implementation onlyfor clang, as it uses clang specific builtins, and does not compilecorrectly with gcc. Note that gcc packages usually come with
Follow-up r364753 by enabling compiler-rt's atomic implementation onlyfor clang, as it uses clang specific builtins, and does not compilecorrectly with gcc. Note that gcc packages usually come with their ownlibatomic, providing these primitives.PR: 230888MFC after: 3 daysX-MFC-With: r364753
After r364753, there should be no need to suppress -Watomic-alignmentwarnings anymore for compiler-rt's atomic.c. This occurred because theIS_LOCK_FREE_8 macro was not correctly defined to 0 for mi
After r364753, there should be no need to suppress -Watomic-alignmentwarnings anymore for compiler-rt's atomic.c. This occurred because theIS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and thiscaused the compiler to emit a runtime call to __atomic_is_lock_free(),and that triggers the warning.MFC after: 2 weeksX-MFC-With: r364753
Add atomic and bswap functions to libcompiler_rtThere have been several mentions on our mailing lists about missingatomic functions in our system libraries (e.g. __atomic_load_8 andfriends), and
Add atomic and bswap functions to libcompiler_rtThere have been several mentions on our mailing lists about missingatomic functions in our system libraries (e.g. __atomic_load_8 andfriends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.To address this, add implementations for the functions from compiler-rtto the system compiler support libraries, e.g. libcompiler_rt.a and andlibgcc_s.so.This also needs a small fixup in compiler-rt's atomic.c, to ensure that32-bit mips can build correctly.Bump __FreeBSD_version to make it easier for port maintainers to detectwhen these functions were added.MFC after: 2 weeksDifferential Revision: https://reviews.freebsd.org/D26159
Avoid adding duplicates to SRCS/OBJS/SOBJS/POBJSThis is a change in preparation for stopping to use lorder.sh (D26044) andinstead assume that we have a linker newer than ~1990. Without lorder.shd
Avoid adding duplicates to SRCS/OBJS/SOBJS/POBJSThis is a change in preparation for stopping to use lorder.sh (D26044) andinstead assume that we have a linker newer than ~1990. Without lorder.shduplicates end up being passed to the linker when building .so files and thiscan result in duplicate symbol definition errors.There is one minor change: libcompiler_rt.a will no longer providegcc_personality_v0 and instead we now only have it in libgcc_eh.a/libgcc_s.so.This matches GCC's behaviour.Reviewed By: emaste, cemDifferential Revision: https://reviews.freebsd.org/D26042
Merge ^/head r357662 through r357854.
Remove sparc64 specific inclusion of bswap32 built-ins.
Add internal floating point environment builtins to libcompiler_rt andlibgcc, as these are used in a few other builtin implementations.
Sort libcompiler_rt sources.
[PowerPC] enable atomic.c in compiler_rt and do not check and forceslock/lock_free decisions in compiled timeSummary:Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim
[PowerPC] enable atomic.c in compiler_rt and do not check and forceslock/lock_free decisions in compiled timeSummary:Enables atomic.c in compiler_rt and forces clang to not emit a call for runtimedecision about lock/lock_free. At compiling time, if clang can't decide ifatomic operation can be lock free, it emits calls to external functions like`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and`__atomic_always_lock_free`, postponing decision to a runtime check. Accordingto LLVM code documentation, the mechanism exists due to differences betweenx86_64 processors that can't be decided at runtime.On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lockfree, so we force the decision at compile time and avoid having to implement itin an external library.This patch was made after 32 bit users testing the PowePC32 bit ISO reportedllvm could not be compiled with in-base llvm due to `__atomic_load8` notimplemented.Submitted by: alfredo.junior_eldorado.org.brReviewed by: jhibbits, dimDifferential Revision: https://reviews.freebsd.org/D22549
Move all sources from the llvm project into contrib/llvm-project.This uses the new layout of the upstream repository, which was recentlymigrated to GitHub, and converted into a "monorepo". That i
Move all sources from the llvm project into contrib/llvm-project.This uses the new layout of the upstream repository, which was recentlymigrated to GitHub, and converted into a "monorepo". That is, most ofthe earlier separate sub-projects with their own branches and tags wereconsolidated into one top-level directory, and are now branched andtagged together.Updating the vendor area to match this layout is next.
Define __SOFT_FP__ for riscv64sf to avoid infinite recursion.Submitted by: James Clarke <jrtc27@jrtc27.com>Reviewed by: impSponsored by: DARPADifferential Revision: https://reviews.freebsd.org/D
Define __SOFT_FP__ for riscv64sf to avoid infinite recursion.Submitted by: James Clarke <jrtc27@jrtc27.com>Reviewed by: impSponsored by: DARPADifferential Revision: https://reviews.freebsd.org/D22660
Fix llvm-libunwind userspace build on ARMGCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, orEHABI or whatever it's called. Export the same ones from LLVM-libunwind'slibgcc_s,
Fix llvm-libunwind userspace build on ARMGCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, orEHABI or whatever it's called. Export the same ones from LLVM-libunwind'slibgcc_s, on ARM. As part of this, convert libgcc_s from a directVersion.map to one constructed from component Symbol.map files. This allowsthe ARM-specific Symbol.map to be included only on ARM.Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to matchnon-ARM definitions and ARM-specific expectations in libcxxrt /libcompiler_rt.No functional change intended for non-ARM architectures.This commit does not actually flip the switch for ARM defaults from libgccto llvm-libunwind, but makes it possible (to compile, anyway).
Update build glue for building compiler-rt.
compiler-rt: enable __bswapsi2/__bswapdi2 for RISC-VAs with other archs the compiler may emit calls to the byte swap routinesunder certain conditions.MFC after: 1 weekSponsored by: The FreeBSD
compiler-rt: enable __bswapsi2/__bswapdi2 for RISC-VAs with other archs the compiler may emit calls to the byte swap routinesunder certain conditions.MFC after: 1 weekSponsored by: The FreeBSD Foundation
The routines defined in comparedf2 and comparesf2 are defined in libcfor softfloat mips. No need to include them here.
Support armv7 builds for userlandMake armv7 as a new MACHINE_ARCH.Copy all the places we do armv6 and add armv7 as basically analias. clang appears to generate code for armv7 by default. armv7 h
Support armv7 builds for userlandMake armv7 as a new MACHINE_ARCH.Copy all the places we do armv6 and add armv7 as basically analias. clang appears to generate code for armv7 by default. armv7 hardfloat isn't supported by the the in-tree gcc, so it hasn't beenupdated to have a new default.Support armv7 as a new valid MACHINE_ARCH (and by extensionTARGET_ARCH).Add armv7 to the universe build.Differential Revision: https://reviews.freebsd.org/D12010
Follow-up to r323001: if the actually selected CPUTYPE is capable ofSSE2 instructions, we can use them.Suggested by: jkimPR: 221733MFC after: 1 weekX-MFC-With: r323001
In compiler-rt, a few assembler implementations for i386 floating pointconversion functions use SSE2 instructions, but these are not guarded by#ifdef __SSE2__, and there is no implementation using
In compiler-rt, a few assembler implementations for i386 floating pointconversion functions use SSE2 instructions, but these are not guarded by#ifdef __SSE2__, and there is no implementation using general purposeregisters. For these functions, use the generic C variants instead,otherwise they will cause SIGILL on older processors.Reported by: bsdpr@phoe.frmug.orgPR: 221733MFC after: 1 week
Include {u,}{div,mod}si3() on mips in libcompiler_rt.These builtins were listed in the mips-specific Symbol.map for libc butwere not implemented. Compiling mips with recent clang requires theses
Include {u,}{div,mod}si3() on mips in libcompiler_rt.These builtins were listed in the mips-specific Symbol.map for libc butwere not implemented. Compiling mips with recent clang requires thesesymbols.Sponsored by: DARPA / AFRL
There is no MACHINE_CPUARCH == armv6, remove redunant check.
Merge ^/head r320573 through r320970.
compiler_rt: provide bswap buildins on sparc64Attempting to build sparc64 world with GCC 6.3 previously failed withzstd_compress.c:(.text+0x8fc): undefined reference to `__bswapsi2'
Merge ^/head r318560 through r318657.
12345