aboutsummaryrefslogtreecommitdiff
path: root/contrib/llvm-project
Commit message (Collapse)AuthorAgeFilesLines
* Reapply "Merge commit e24f90190c77 from llvm git (by Brad Smith):"Dimitry Andric8 days1-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089) The compiler_rt helper functions have been built since 12.4, 13.1, 14 and anything newer. This reverts commit bd27bd1f51d049538cc7a0053be9d99110a53ae1. Only some people (including the release manager, unfortunately) ran into build issues with the previous iteration of this commit, because they were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER src.conf(5) setting, or because the build system determined that their base system compiler was out of date. The bootstrapped compiler would then enable outline atomics and compile libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs, it could not find the helper routines in libcompiler_rt.a. In contrast, people who did not bootstrap the compiler never saw any issues, because libgcc_s was built using their 'old' base system compiler, and so libgcc_s would not contain any calls to those helper routines. Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a explicitly, similar to some other binaries and libraries that are built with -nodefaultlibs. Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated compiler with outline atomics enabled. (This should have been done in the first iteration of this commit, because the error would have shown up right away then.) MFC after: 3 days
* lldb: Fix empty register set when trying to get size of registerShengYi Hung8 days1-24/+20
| | | | | | | | | | | | The register set information is stored as a singleton in GetRegisterInfo_i386. However, other functions later access this information assuming it is stored in GetSharedRegisterInfoVector. To resolve this inconsistency, we remove the original construction logic and instead initialize the singleton using llvm::call_once within the appropriate function (GetSharedRegisterInfoVector_i386). PR: 289945 Obtained from: llvm-project 41859c27842eeda1ef6ff18f3b2fb269388c0857
* lldb: Fix Architecture parsing by reading the ELF header. (#162811)ShengYi Hung8 days1-13/+28
| | | | | | | | | | | | | | Currently, LLDB in FreeBSD host sets the Process Architecture used by lldbserver as Default one. Which cause problem when trying to debug a 32bit binary on amd64 platform since the lldb itself will found mismatch architecture with lldbserver's return. Notice that this patch is only a partial fix for the debugging problem. We are still unable to debug x86 on x86_64 so that we don't provide testcase in this patch. PR: 289945 Obtained from: llvm-project 394e7ded8b6bcff1382468b407ca620a2837f41b
* Revert "Merge commit e24f90190c77 from llvm git (by Brad Smith):"Dimitry Andric2025-10-311-5/+0
| | | | | | | | | | | [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089) The compiler_rt helper functions have been built since 12.4, 13.1, 14 and anything newer. This reverts commit 51e8e8b0f36933814b1be08913857727876aece5. MFC after: immediately
* Merge commit e24f90190c77 from llvm git (by Brad Smith):Dimitry Andric2025-10-291-0/+5
| | | | | | | | | [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089) The compiler_rt helper functions have been built since 12.4, 13.1, 14 and anything newer. MFC after: 3 days
* libc++: silence -Wnontrivial-memaccess warning with newer clangAlex Richardson2025-09-151-1/+2
| | | | | | | | | | | | | | | | | Apply part of LLVM commit 71315698c91d0cda054b903da0594ca6f072c350 to silence the -Wnontrivial-memaccess warning that is triggered any time this function is instantiated by user code. This fixes another buildworld failure with Clang HEAD. Original commit message: [clang] Warn about memset/memcpy to NonTriviallyCopyable types (#111434) This implements a warning that's similar to what GCC does in that context: both memcpy and memset require their first and second operand to be trivially copyable, let's warn if that's not the case. Reviewed by: emaste, dim MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52534
* libc++: Fix deprecation warnings with latest clangAlex Richardson2025-09-154-6/+8
| | | | | | | | | | | | | | | Latest clang has become more strict in diagnosing deprecated decls, so pull in LLVM commit 9feac2cbd0d80927ce9a8b4c3e810d2b81802d55. Original commit message: [libc++] Improve deprecated diagnostic guards. Recent Clang-21 builds improved the deprecated diagnotics. This uncovered missing guards in libc++ internally. Reviewed by: dim MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52531
* libc++: avoid use of deprecated __reference_binds_to_temporaryAlex Richardson2025-09-151-1/+3
| | | | | | | | | | | | This was removed in upstream libc++ in commit 437ad06f762ab07d89badecdd20627db200b98d3, but as this does not apply cleanly to the current repository, I am applying the equivalent change in a minimally invasive way. This is needed to build with latest clang HEAD as of today. Reviewed by: dim MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52530
* libc++: avoid use of deprecated builtinAlex Richardson2025-09-151-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This pulls in LLVM commit accfbd4cb327411ad66c0109ba1841482b871967 to avoid the use of __libcpp_is_trivially_relocatable. This fixes building FreeBSD libc++ with clang HEAD as of today. Original commit message: [libc++] Replace __is_trivially_relocatable by is_trivially_copyable (#124970) The __is_trivially_relocatable builtin has semantics that do not correspond to any current or future notion of trivial relocation. Furthermore, it currently leads to incorrect optimizations for some types on supported compilers: - Clang on Windows where types with non-trivial destructors get incorrectly optimized - AppleClang where types with non-trivial move constructors get incorrectly optimized Until there is an agreed upon and bugfree implementation of what it means to be trivially relocatable, it is safer to simply use trivially copyable instead. This doesn't leave a lot of types behind and is definitely correct. Reviewed by: dim MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52529
* Merge commit 7a66a26658f4 from llvm git (by Fangrui Song):Ed Maste2025-08-281-12/+13
| | | | | | | | | | | | | | | | | | | --discard-locals/--discard-all: allow and keep symbols referenced by relocations In GNU objcopy, symbols referenced by relocations are retained. Our COFF (https://reviews.llvm.org/D56480) and Mach-O (https://reviews.llvm.org/D75104) ports port the behavior, but the ELF port doesn't. This PR implements the behavior for ELF. Close #47468 (tcl has a use case that requires `strip -x tclStubLib.o` to strip local symbols not referenced by relocations.) Pull Request: https://github.com/llvm/llvm-project/pull/130704 PR: 258820 Approved by: dim Differential Revision: https://reviews.freebsd.org/D52198
* Merge commit cf721e29c6a3 from llvm git (by Amy Kwan):Dimitry Andric2025-08-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | [PowerPC] Do not merge TLS constants within PPCMergeStringPool.cpp (#94059) This patch prevents thread-local constants to be merged within PPCMergeStringPool.cpp. The PPCMergeStringPool pass primarily merges non-thread-local constants together, and thread-local constants should not be mixed together with other (non-thread-local) constants. In the event that thread-local and other non-thread-local constants are pooled together, the llvm.threadlocal.address intrinsic can fail as it expects its argument to be a thread-local global value, but the merged string structure created by the PPCMergeStringPool pass is not thread-local as a whole. This fixes an error "llvm.threadlocal.address first argument must be a GlobalValue" when building the math/nauty port on PowerPC architectures. PR: 289122 Reported by: pkubaj MFC after: 3 days
* Merge commit 8ac140f39084 from llvm git (by Younan Zhang):Dimitry Andric2025-07-213-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Clang][NFCI] Cleanup the fix for default function argument substitution (#104911) (This is one step towards tweaking `getTemplateInstantiationArgs()` as discussed in https://github.com/llvm/llvm-project/pull/102922) We don't always substitute into default arguments while transforming a function parameter. In that case, we would preserve the uninstantiated expression until after, e.g. building up a CXXDefaultArgExpr and instantiate the expression there. For member function instantiation, this algorithm used to cause a problem in that the default argument of an out-of-line member function specialization couldn't get properly instantiated. This is because, in `getTemplateInstantiationArgs()`, we would give up visiting a function's declaration context if the function is a specialization of a member template. For example, ```cpp template <class T> struct S { template <class U> void f(T = sizeof(T)); }; template <> template <class U> void S<int>::f(int) {} ``` The default argument `sizeof(U)` that lexically appears inside the declaration would be copied to the function declaration in the class template specialization `S<int>`, as well as to the function's out-of-line definition. We use template arguments collected from the out-of-line function definition when substituting into the default arguments. We would therefore give up the traversal after the function, resulting in a single-level template argument of the `f` itself. However the default argument here could still reference the template parameters of the primary template, hence the error. In fact, this is similar to constraint checking in some respects: we actually want the "whole" template arguments relative to the primary template, not those relative to the function definition. So this patch adds another flag to indicate `getTemplateInstantiationArgs()` for that. This patch also consolidates the tests for default arguments and removes some unnecessary tests. This fixes a crash or assertion failure while building tests for the devel/hpx port. PR: 288352 MFC after: 3 days
* contrib/llvm-project: re-add clang/tools/clang-scan-depsDimitry Andric2025-06-253-2/+1098
| | | | | | This is in preparation for adding it as an optional tool in base. MFC after: 1 week
* contrib/llvm-project: fix clang crash compiling modulesLexi Winter2025-06-257-18/+91
| | | | | | | | | | | | | | | clang++ may crash when compiling certain C++20 modules. Backport the fix from LLVM upstream. This fixes LLVM bug 102684: https://github.com/llvm/llvm-project/issues/102684. PR: 287803 MFC after: 3 days Obtained from: https://github.com/llvm/llvm-project/pull/102855 Reviewed by: kevans, dim Approved by: kevans (mentor) Differential Revision: https://reviews.freebsd.org/D51041
* libc++: fix compiling <locale> with -fmodulesJordan Gordeev2025-05-181-1/+7
| | | | | | | | | | | | | | | | | In /usr/include/c++/v1/__locale_dir/locale_base_api.h, xlocale.h is included without first including stdio.h and stdlib.h, which causes functions like strtoll_l() or sscanf_l() to not be declared. When compiling with -fmodules, locale_base_api.h is processed separately due to a declaration in /usr/include/c++/v1/module.modulemap, and this will cause errors due to the above undeclared symbols. Meanwhile, upstream has substantially reorganized this part of libc++'s headers, so apply a minimalistic workaround: specifically when compiling with -fmodules, add includes of stdio.h and stdlib.h. PR: 286342 MFC after: 1 week
* Merge llvm-project release/19.x llvmorg-19.1.7-0-gcd708029e0b2Dimitry Andric2025-01-1618-72/+123
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.7-0-gcd708029e0b2, a.k.a. 19.1.7 release. PR: 280562 MFC after: 3 days
* Merge llvm-project release/19.x llvmorg-19.1.5-0-gab4b5a2db582Dimitry Andric2024-12-0629-101/+210
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.5-0-gab4b5a2db582, a.k.a. 19.1.5 release. PR: 280562 MFC after: 3 days
* Merge llvm-project release/19.x llvmorg-19.1.4-0-gaadaa00de76eDimitry Andric2024-11-2128-253/+355
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.4-0-gaadaa00de76e, a.k.a. 19.1.4 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.3-0-gab51eccf88f5Dimitry Andric2024-11-0828-80/+185
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.3-0-gab51eccf88f5, a.k.a. 19.1.3 release. PR: 280562 MFC after: 1 month
* Tentatively merge llvm fix for buildworld WITH_ASANDimitry Andric2024-10-281-1/+1
| | | | | | | | | | | | | | | | | Building world using WITH_ASAN results in an assertion when compiling certain source files referencing ifuncs: Assertion failed: (isa<Function>(Callee) || isa<GlobalAlias>(Callee)), function analyzeAllUses, file /root/freebsd/contrib/llvm-project/llvm/lib/Analysis/StackSafetyAnalysis.cpp, line 514. This was already reported upstream a while ago, in <https://github.com/llvm/llvm-project/issues/87923>, but now there is finally a candidate fix, which seems trivial so I am importing it right away. Reported by: markj PR: 280936 Pull Request: https://github.com/llvm/llvm-project/pull/113841 MFC after: 3 days
* Fix buildworld with gcc 12 after llvm-19 importDimitry Andric2024-10-251-0/+2
| | | | | | | | | | | | | | | | | | | | | Unfortunately gcc 12's is not yet capable of compiling all of libc++ 19's C++23 code, which results in errors similar to: /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:41:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Iter, _Sent, const _Type&, _Proj)' must be a non-static member function 41 | operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = {}) { | ^~~~~~~~ /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:48:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Range&&, const _Type&, _Proj)' must be a non-static member function 48 | operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) { | ^~~~~~~~ Until we can get rid of gcc 12, work around this by making it compile libc++ in C++20 mode instead. NOTE: The resulting libc++ library will not be C++23 compatible! Please try to avoid shipping it, and use gcc 13 instead, if you must use gcc. PR: 280562 MFC after: 3 days
* Apply workaround for building llvm-project with WITHOUT_LLVM_ASSERTIONSDimitry Andric2024-10-244-12/+12
| | | | | | | | | | | | | | | | | Some internal checking functions should only be declared when both NDEBUG and LLVM_ENABLE_ABI_BREAKING_CHECKS are undefined, otherwise you would get compile errors similar to: /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:921:13: error: no member named 'VerifyDAGDivergence' in 'llvm::SelectionDAG' 921 | CurDAG->VerifyDAGDivergence(); | ~~~~~~ ^ Adjust the conditions for declaring and using these functions. This has also been reported upstream. Reported by: cy PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6Dimitry Andric2024-10-2330-335/+245
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6, a.k.a. 19.1.2 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349Dimitry Andric2024-10-2333-77/+315
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349, a.k.a. 19.1.1 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1Dimitry Andric2024-10-2330-175/+225
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1, a.k.a. 19.1.0 release. PR: 280562 MFC after: 1 month
* Merge commit 6dbdb8430b49 from llvm git (by Nikolas Klauser):Dimitry Andric2024-10-231-1/+2
| | | | | | | | | | | | | [Clang] Fix crash due to invalid source location in __is_trivially_equality_comparable (#107815) Fixes #107777 This fixes an assertion failure building www/qt5-webengine: Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"), function setPointOfInstantiation, file contrib/llvm-project/clang/include/clang/AST/DeclTemplate.h, line 1938. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515aDimitry Andric2024-10-2354-271/+405
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8Dimitry Andric2024-10-23110-1442/+1223
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1cDimitry Andric2024-10-2382-689/+1094
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-4003-g55357160d0e1:Dimitry Andric2024-10-232-13/+13
| | | | | | | | | | | [libc++] Use GCC type traits builtins for remove_cv and remove_cvref (#81386) They have been added recently to GCC without support for mangling. This patch uses them in structs and adds aliases to these structs instead of the builtins directly. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-4504-g937a5396cf3e:Dimitry Andric2024-10-231-0/+6
| | | | | | | [libc++] Remove unused includes from __type_traits/is_convertible.h (#83747) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-5639-ga10aa4485e83:Dimitry Andric2024-10-233-15/+7
| | | | | | | | | | [libc++] Simplify the implementation of remove_reference (#85207) GCC 13 introduced the type trait `__remove_reference`. We can simplify the implementation of `remove_reference` a bit by using it. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-8667-g472b612ccbed:Dimitry Andric2024-10-232-1/+2
| | | | | | | [libc++][NFC] Remove unused includes from <__type_traits/remove_cv.h> (#88752) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17473-g69fecaa1a455:Dimitry Andric2024-10-2310-31/+266
| | | | | | | [libc++] Clean up some now dead code with the upgrade to GCC 14 (#97746) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17727-g0eebb48fcfbc:Dimitry Andric2024-10-236-13/+68
| | | | | | | | | | [libc++] Merge is_member{,_object,_function}_pointer.h (#98727) The implementations for these traits have been simplified quite a bit, since we have builtins available for them now. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17728-g30cc12cd818d:Dimitry Andric2024-10-233-5/+11
| | | | | | | [libc++] Simplify the implementation of is_null_pointer a bit (#98728) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17853-g578c6191eff7:Dimitry Andric2024-10-231-2/+18
| | | | | | | [libc++] Simplify std::is_void (#99033) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-18062-g4dfa75c663e5:Dimitry Andric2024-10-234-10/+38
| | | | | | | [libc++] Merge is_scoped_enum.h into is_enum.h (#99458) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-18063-g561246e90282:Dimitry Andric2024-10-231-1/+1
| | | | | | | [libc++][NFC] Remove wrong #endif comment PR: 280562 MFC after: 1 month
* libcxx cstdlib, cwchar: avoid using long long functions if notDimitry Andric2024-10-232-0/+16
| | | | | | | | supported, even for older compilers that do not support the using_if_exists attribute. PR: 280562 MFC after: 1 month
* libcxx atomic_ref.h: add typename keyword for difference_typeDimitry Andric2024-10-231-2/+2
| | | | | | | declarations, otherwise older clang versions cannot compile this header. PR: 280562 MFC after: 1 month
* libcxx simd_utils.h: only enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS forDimitry Andric2024-10-231-1/+1
| | | | | | | clang >= 15, since older versions do not support the required builtins. PR: 280562 MFC after: 1 month
* Tentatively apply https://github.com/llvm/llvm-project/pull/101403Dimitry Andric2024-10-233-3/+3
| | | | | PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2Dimitry Andric2024-10-2378-321/+768
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2. PR: 280562 MFC after: 1 month
* Merge llvm-project main llvmorg-19-init-18630-gf2ccf80136a0Dimitry Andric2024-10-235747-218816/+421501
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-19-init-18630-gf2ccf80136a0, the last commit before the upstream release/19.x branch was created. PR: 280562 MFC after: 1 month
* Merge commit b84d773fd004 from llvm git (by Fangrui Song):Dimitry Andric2024-09-223-61/+48
| | | | | | | | | | | | | | | | | | | | | | | | | [Parallel] Revert sequential task changes https://reviews.llvm.org/D148728 introduced `bool Sequential` to unify `execute` and the old `spawn` without argument. However, sequential tasks might be executed by any worker thread (non-deterministic), leading to non-determinism output for ld.lld -z nocombreloc (see https://reviews.llvm.org/D133003). In addition, the extra member variables have overhead. This sequential task has only been used for lld parallel relocation scanning. This patch restores the behavior before https://reviews.llvm.org/D148728 . Fix #105958 Pull Request: https://github.com/llvm/llvm-project/pull/109084 This fixes the non-reproducibility we had noticed when linking our EFI loaders, and for which we committed a workaround in f5ce3f4ef562. MFC after: 3 days
* Merge commit d2353ae00c3b from llvm git (by Argyrios Kyrtzidis):Dimitry Andric2024-08-101-3/+3
| | | | | | | | | | | | | | | | | | | | [utils/TableGen/X86CompressEVEXTablesEmitter.cpp] Make sure the tablegen output for the `checkPredicate` function is deterministic (#84533) The output for the `checkPredicate` function was depending on a `std::map` iteration that was non-deterministic from run to run, because the keys were pointer values. Make a change so that the keys are `StringRef`s so the ordering is stable. This avoids non-determinism in llvm-tblgen output, which could cause differences in the generated X86GenCompressEVEXTables.inc file. Although these differences are not influencing the meaning of the generated code, they still change a few bytes in libllvm. This in turn influences all the binaries linked with libllvm, such as clang, ld.lld, etc. Reported by: cperciva MFC after: 3 days
* Merge commit cb7a03b41fff from llvm git (by Nikolas Klauser):John Baldwin2024-08-053-1/+9
| | | | | | | | | [libc++] Fix failures with GCC 14 (#92663) Fixes #91831 Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D46003
* Merge commit c80c09f3e380 from llvm-project (by Dimitry Andric):Dimitry Andric2024-07-282-5/+14
| | | | | | | | | | | | | | | | | | | | | | [CalcSpillWeights] Avoid x87 excess precision influencing weight result Fixes #99396 The result of `VirtRegAuxInfo::weightCalcHelper` can be influenced by x87 excess precision, which can result in slightly different register choices when the compiler is hosted on x86_64 or i386. This leads to different object file output when cross-compiling to i386, or native. Similar to 7af3432e22b0, we need to add a `volatile` qualifier to the local `Weight` variable to force it onto the stack, and avoid the excess precision. Define `stack_float_t` in `MathExtras.h` for this purpose, and use it. This is the version of the fix for PR276961 that landed upstream. PR: 276961 Reported by: cperciva MFC after: 3 days
* Revert "Fix llvm register allocator for native/cross build differences"Dimitry Andric2024-07-281-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for applying the fix that landed upstream, this reverts commit 397c2693fa66508cb5e6b173650a1f3bc6c4dd4f: Fix llvm register allocator for native/cross build differences Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or cross build of clang. This adds another volatile qualifier to a float variable declaration in the weightCalcHelper() function, which otherwise produces slightly different float results on amd64 and i386 hosts. In turn, this can lead to different (but equivalent) register choices, and thus non-identical assembly code. See https://github.com/llvm/llvm-project/issues/99396 for more details. Note this is a temporary fix, meant to merge in time for 13.4. As soon as upstream has a permanent solution we will import that. PR: 276961 Reported by: cperciva MFC after: 3 days
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-01 07:06:08 +0000