forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[include-cleaner] Treat include_next as exporting #2
Closed
kadircet
wants to merge
2
commits into
export_both_stdlib_and_physical
from
treat_include_next_as_export
Closed
[include-cleaner] Treat include_next as exporting #2
kadircet
wants to merge
2
commits into
export_both_stdlib_and_physical
from
treat_include_next_as_export
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… files This was creating discrepancy in cases where we might have a physical file entry (e.g. because we followed a source location from a stdlib file) and tried to find its exporters.
Most of the time the included-header cannot be just `#include`d from user code, and providing findings asking for the inclusion of the inner header seems wrong. We have enough explicit intent from the developer around included header and including header being related via use of include_next directive, instead of a regular include. So this patch proposes to treat the inner header as being exported so that the user can only include the outer header. This also works nicely when the user is transitively relying on inner header, we'll still suggest including that one and if the spelling of inner and outer headers are different that inclusion will be correct. Otherwise if the spellings are the same, we'll treat the outer header as the provider.
kadircet
force-pushed
the
export_both_stdlib_and_physical
branch
from
November 17, 2023 09:10
49ea3ae
to
84f320a
Compare
kadircet
pushed a commit
that referenced
this pull request
Dec 19, 2023
Linalg op fusion (`Linalg/Transforms/Fusion.cpp`) used to generate invalid fused producer ops: ``` error: 'linalg.conv_2d_nhwc_hwcf' op expected type of operand #2 ('tensor<1x8x16x4xf32>') to match type of corresponding result ('tensor<?x?x?x?xf32>') note: see current operation: %24 = "linalg.conv_2d_nhwc_hwcf"(%21, %22, %23) <{dilations = dense<1> : tensor<2xi64>, operandSegmentSizes = array<i32: 2, 1>, strides = dense<2> : tensor<2xi64>}> ({ ^bb0(%arg9: f32, %arg10: f32, %arg11: f32): %28 = "arith.mulf"(%arg9, %arg10) <{fastmath = #arith.fastmath<none>}> : (f32, f32) -> f32 %29 = "arith.addf"(%arg11, %28) <{fastmath = #arith.fastmath<none>}> : (f32, f32) -> f32 "linalg.yield"(%29) : (f32) -> () }) {linalg.memoized_indexing_maps = [affine_map<(d0, d1, d2, d3, d4, d5, d6) -> (d0, d1 * 2 + d4, d2 * 2 + d5, d6)>, affine_map<(d0, d1, d2, d3, d4, d5, d6) -> (d4, d5, d6, d3)>, affine_map<(d0, d1, d2, d3, d4, d5, d6) -> (d0, d1, d2, d3)>]} : (tensor<1x?x?x3xf32>, tensor<3x3x3x4xf32>, tensor<1x8x16x4xf32>) -> tensor<?x?x?x?xf32> ``` This is a problem because the input IR to greedy pattern rewriter during `-test-linalg-greedy-fusion` is invalid. This commit fixes tests such as `mlir/test/Dialect/Linalg/tile-and-fuse-tensors.mlir` when verifying the IR after each pattern application (llvm#74270).
kadircet
pushed a commit
that referenced
this pull request
Jan 3, 2024
This has been flaky for a while, for example https://lab.llvm.org/buildbot/#/builders/96/builds/50350 ``` Command Output (stdout): -- lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision 3974d89) clang revision 3974d89 llvm revision 3974d89 "can't evaluate expressions when the process is running." ``` ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. #0 0x0000ffffa46191a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a1a0) #1 0x0000ffffa4617144 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x5298144) #2 0x0000ffffa46198d0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x529a8d0) llvm#3 0x0000ffffab25b7dc (linux-vdso.so.1+0x7dc) llvm#4 0x0000ffffab13d050 /build/glibc-Q8DG8B/glibc-2.31/string/../sysdeps/aarch64/multiarch/memcpy_advsimd.S:92:0 llvm#5 0x0000ffffa446f420 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::PrivateSetRegisterValue(unsigned int, llvm::ArrayRef<unsigned char>) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0420) llvm#6 0x0000ffffa446f7b8 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::GetPrimordialRegister(lldb_private::RegisterInfo const*, lldb_private::process_gdb_remote::GDBRemoteCommunicationClient&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f07b8) llvm#7 0x0000ffffa446f308 lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegisterBytes(lldb_private::RegisterInfo const*) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50f0308) llvm#8 0x0000ffffa446ec1c lldb_private::process_gdb_remote::GDBRemoteRegisterContext::ReadRegister(lldb_private::RegisterInfo const*, lldb_private::RegisterValue&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x50efc1c) llvm#9 0x0000ffffa412eaa4 lldb_private::RegisterContext::ReadRegisterAsUnsigned(lldb_private::RegisterInfo const*, unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4dafaa4) llvm#10 0x0000ffffa420861c ReadLinuxProcessAddressMask(std::shared_ptr<lldb_private::Process>, llvm::StringRef) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e8961c) llvm#11 0x0000ffffa4208430 ABISysV_arm64::FixCodeAddress(unsigned long) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_lldb.cpython-38-aarch64-linux-gnu.so+0x4e89430) ``` Judging by the backtrace something is trying to read the pointer authentication address/code mask registers. This explains why I've not seen this issue locally, as the buildbot runs on Graviton 3 with has the pointer authentication extension. I will try to reproduce, fix and re-enable the test.
kadircet
pushed a commit
that referenced
this pull request
Feb 29, 2024
…ter partial ordering when determining primary template (llvm#82417) Consider the following: ``` struct A { static constexpr bool x = true; }; template<typename T, typename U> void f(T, U) noexcept(T::y); // #1, error: no member named 'y' in 'A' template<typename T, typename U> void f(T, U*) noexcept(T::x); // #2 template<> void f(A, int*) noexcept; // explicit specialization of #2 ``` We currently instantiate the exception specification of all candidate function template specializations when deducting template arguments for an explicit specialization, which results in a error despite `#1` not being selected by partial ordering as the most specialized template. According to [except.spec] p13: > An exception specification is considered to be needed when: > - [...] > - the exception specification is compared to that of another declaration (e.g., an explicit specialization or an overriding virtual function); Assuming that "comparing declarations" means "determining whether the declarations correspond and declare the same entity" (per [basic.scope.scope] p4 and [basic.link] p11.1, respectively), the exception specification does _not_ need to be instantiated until _after_ partial ordering, at which point we determine whether the implicitly instantiated specialization and the explicit specialization declare the same entity (the determination of whether two functions/function templates correspond does not consider the exception specifications). This patch defers the instantiation of the exception specification until a single function template specialization is selected via partial ordering, matching the behavior of GCC, EDG, and MSVC: see https://godbolt.org/z/Ebb6GTcWE.
kadircet
pushed a commit
that referenced
this pull request
May 24, 2024
…llvm#92855) This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. When performing template argument deduction, we extend the provisional wording introduced in llvm#89807 so it also covers deduction of class templates. Given the following example: ```C++ template <class T1, class T2 = float> struct A; template <class T3> struct B; template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1 template <class T6, class T7> struct B<A<T6, T7>>; // #2 template struct B<A<int>>; ``` Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This patch restores the pre-P0522 behavior, `#2` is picked again. This has the beneficial side effect of making the following code valid: ```C++ template<class T, class U> struct A {}; A<int, float> v; template<template<class> class TT> void f(TT<int>); // OK: TT picks 'float' as the default argument for the second parameter. void g() { f(v); } ``` --- Since this changes provisional implementation of CWG2398 which has not been released yet, and already contains a changelog entry, we don't provide a changelog entry here.
kadircet
pushed a commit
that referenced
this pull request
Aug 20, 2024
…lvm#104148) `hasOperands` does not always execute matchers in the order they are written. This can cause issue in code using bindings when one operand matcher is relying on a binding set by the other. With this change, the first matcher present in the code is always executed first and any binding it sets are available to the second matcher. Simple example with current version (1 match) and new version (2 matches): ```bash > cat tmp.cpp int a = 13; int b = ((int) a) - a; int c = a - ((int) a); > clang-query tmp.cpp clang-query> set traversal IgnoreUnlessSpelledInSource clang-query> m binaryOperator(hasOperands(cStyleCastExpr(has(declRefExpr(hasDeclaration(valueDecl().bind("d"))))), declRefExpr(hasDeclaration(valueDecl(equalsBoundNode("d")))))) Match #1: tmp.cpp:1:1: note: "d" binds here int a = 13; ^~~~~~~~~~ tmp.cpp:2:9: note: "root" binds here int b = ((int)a) - a; ^~~~~~~~~~~~ 1 match. > ./build/bin/clang-query tmp.cpp clang-query> set traversal IgnoreUnlessSpelledInSource clang-query> m binaryOperator(hasOperands(cStyleCastExpr(has(declRefExpr(hasDeclaration(valueDecl().bind("d"))))), declRefExpr(hasDeclaration(valueDecl(equalsBoundNode("d")))))) Match #1: tmp.cpp:1:1: note: "d" binds here 1 | int a = 13; | ^~~~~~~~~~ tmp.cpp:2:9: note: "root" binds here 2 | int b = ((int)a) - a; | ^~~~~~~~~~~~ Match #2: tmp.cpp:1:1: note: "d" binds here 1 | int a = 13; | ^~~~~~~~~~ tmp.cpp:3:9: note: "root" binds here 3 | int c = a - ((int)a); | ^~~~~~~~~~~~ 2 matches. ``` If this should be documented or regression tested anywhere please let me know where.
kadircet
pushed a commit
that referenced
this pull request
Aug 22, 2024
…104523) Compilers and language runtimes often use helper functions that are fundamentally uninteresting when debugging anything but the compiler/runtime itself. This patch introduces a user-extensible mechanism that allows for these frames to be hidden from backtraces and automatically skipped over when navigating the stack with `up` and `down`. This does not affect the numbering of frames, so `f <N>` will still provide access to the hidden frames. The `bt` output will also print a hint that frames have been hidden. My primary motivation for this feature is to hide thunks in the Swift programming language, but I'm including an example recognizer for `std::function::operator()` that I wished for myself many times while debugging LLDB. rdar://126629381 Example output. (Yes, my proof-of-concept recognizer could hide even more frames if we had a method that returned the function name without the return type or I used something that isn't based off regex, but it's really only meant as an example). before: ``` (lldb) thread backtrace --filtered=false * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame llvm#3: 0x0000000100003968 a.out`std::__1::__function::__alloc_func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()[abi:se200000](this=0x000000016fdff280, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:171:12 frame llvm#4: 0x00000001000026bc a.out`std::__1::__function::__func<int (*)(int, int), std::__1::allocator<int (*)(int, int)>, int (int, int)>::operator()(this=0x000000016fdff278, __arg=0x000000016fdff224, __arg=0x000000016fdff220) at function.h:313:10 frame llvm#5: 0x0000000100003c38 a.out`std::__1::__function::__value_func<int (int, int)>::operator()[abi:se200000](this=0x000000016fdff278, __args=0x000000016fdff224, __args=0x000000016fdff220) const at function.h:430:12 frame llvm#6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame llvm#7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame llvm#8: 0x0000000183cdf154 dyld`start + 2476 (lldb) ``` after ``` (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 * frame #0: 0x0000000100001f04 a.out`foo(x=1, y=1) at main.cpp:4:10 frame #1: 0x0000000100003a00 a.out`decltype(std::declval<int (*&)(int, int)>()(std::declval<int>(), std::declval<int>())) std::__1::__invoke[abi:se200000]<int (*&)(int, int), int, int>(__f=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:149:25 frame #2: 0x000000010000399c a.out`int std::__1::__invoke_void_return_wrapper<int, false>::__call[abi:se200000]<int (*&)(int, int), int, int>(__args=0x000000016fdff280, __args=0x000000016fdff224, __args=0x000000016fdff220) at invoke.h:216:12 frame llvm#6: 0x0000000100002038 a.out`std::__1::function<int (int, int)>::operator()(this= Function = foo(int, int) , __arg=1, __arg=1) const at function.h:989:10 frame llvm#7: 0x0000000100001f64 a.out`main(argc=1, argv=0x000000016fdff4f8) at main.cpp:9:10 frame llvm#8: 0x0000000183cdf154 dyld`start + 2476 Note: Some frames were hidden by frame recognizers ```
kadircet
pushed a commit
that referenced
this pull request
Aug 27, 2024
) Currently, process of replacing bitwise operations consisting of `LSR`/`LSL` with `And` is performed by `DAGCombiner`. However, in certain cases, the `AND` generated by this process can be removed. Consider following case: ``` lsr x8, x8, llvm#56 and x8, x8, #0xfc ldr w0, [x2, x8] ret ``` In this case, we can remove the `AND` by changing the target of `LDR` to `[X2, X8, LSL #2]` and right-shifting amount change to 56 to 58. after changed: ``` lsr x8, x8, llvm#58 ldr w0, [x2, x8, lsl #2] ret ``` This patch checks to see if the `SHIFTING` + `AND` operation on load target can be optimized and optimizes it if it can.
kadircet
pushed a commit
that referenced
this pull request
Aug 28, 2024
`JITDylibSearchOrderResolver` local variable can be destroyed before completion of all callbacks. Capture it together with `Deps` in `OnEmitted` callback. Original error: ``` ==2035==ERROR: AddressSanitizer: stack-use-after-return on address 0x7bebfa155b70 at pc 0x7ff2a9a88b4a bp 0x7bec08d51980 sp 0x7bec08d51978 READ of size 8 at 0x7bebfa155b70 thread T87 (tf_xla-cpu-llvm) #0 0x7ff2a9a88b49 in operator() llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:58 #1 0x7ff2a9a88b49 in __invoke<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:149:25 #2 0x7ff2a9a88b49 in __call<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:224:5 llvm#3 0x7ff2a9a88b49 in operator() libcxx/include/__functional/function.h:210:12 llvm#4 0x7ff2a9a88b49 in void std::__u::__function::__policy_invoker<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, ```
kadircet
pushed a commit
that referenced
this pull request
Sep 13, 2024
Static destructor can race with calls to notify and trigger tsan warning. ``` WARNING: ThreadSanitizer: data race (pid=5787) Write of size 1 at 0x55bec9df8de8 by thread T23: #0 pthread_mutex_destroy [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1344](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1344&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12affb) (BuildId: ff25ace8b17d9863348bb1759c47246c) #1 __libcpp_recursive_mutex_destroy [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:91](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=91&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9) (BuildId: ff25ace8b17d9863348bb1759c47246c) #2 std::__tsan::recursive_mutex::~recursive_mutex() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:52](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=52&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d4e9) llvm#3 ~SmartMutex [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:28](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=28&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#4 (anonymous namespace)::PerfJITEventListener::~PerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:65](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=65&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaedfe) llvm#5 cxa_at_exit_callback_installed_at(void*) [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:437](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=437&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b172cb9) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#6 llvm::JITEventListener::createPerfJITEventListener() [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:496](third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=496&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcad8f5) (BuildId: ff25ace8b17d9863348bb1759c47246c) ``` ``` Previous atomic read of size 1 at 0x55bec9df8de8 by thread T192 (mutexes: write M0, write M1): #0 pthread_mutex_unlock [third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:1387](third_party/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp?l=1387&cl=669089572):3 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x1b12b6bb) (BuildId: ff25ace8b17d9863348bb1759c47246c) #1 __libcpp_recursive_mutex_unlock [third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h:87](third_party/crosstool/v18/stable/src/libcxx/include/__thread/support/pthread.h?l=87&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589) (BuildId: ff25ace8b17d9863348bb1759c47246c) #2 std::__tsan::recursive_mutex::unlock() [third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp:64](third_party/crosstool/v18/stable/src/libcxx/src/mutex.cpp?l=64&cl=669089572):11 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x4523d589) llvm#3 unlock [third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h:47](third_party/llvm/llvm-project/llvm/include/llvm/Support/Mutex.h?l=47&cl=669089572):16 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) (BuildId: ff25ace8b17d9863348bb1759c47246c) llvm#4 ~lock_guard [third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h:39](third_party/crosstool/v18/stable/src/libcxx/include/__mutex/lock_guard.h?l=39&cl=669089572):101 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) llvm#5 (anonymous namespace)::PerfJITEventListener::notifyObjectLoaded(unsigned long, llvm::object::ObjectFile const&, llvm::RuntimeDyld::LoadedObjectInfo const&) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp:290](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/PerfJITEvents/PerfJITEventListener.cpp?l=290&cl=669089572):1 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bcaf968) llvm#6 llvm::orc::RTDyldObjectLinkingLayer::onObjEmit(llvm::orc::MaterializationResponsibility&, llvm::object::OwningBinary<llvm::object::ObjectFile>, std::__tsan::unique_ptr<llvm::RuntimeDyld::MemoryManager, std::__tsan::default_delete<llvm::RuntimeDyld::MemoryManager>>, std::__tsan::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo, std::__tsan::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>, std::__tsan::unique_ptr<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>, std::__tsan::default_delete<llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>, llvm::DenseMapInfo<llvm::orc::JITDylib*, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void>>>>>>, llvm::Error) [third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:386](https://cs.corp.google.com/piper///depot/google3/third_party/llvm/llvm-project/llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp?l=386&cl=669089572):10 (be1eb158bb70fc9cf7be2db70407e512890e5c6e20720cd88c69d7d9c26ea531_0200d5f71908+0x2bc404a8) (BuildId: ff25ace8b17d9863348bb1759c47246c) ```
kadircet
pushed a commit
that referenced
this pull request
Sep 13, 2024
…llvm#94981) This extends default argument deduction to cover class templates as well, applying only to partial ordering, adding to the provisional wording introduced in llvm#89807. This solves some ambuguity introduced in P0522 regarding how template template parameters are partially ordered, and should reduce the negative impact of enabling `-frelaxed-template-template-args` by default. Given the following example: ```C++ template <class T1, class T2 = float> struct A; template <class T3> struct B; template <template <class T4> class TT1, class T5> struct B<TT1<T5>>; // #1 template <class T6, class T7> struct B<A<T6, T7>>; // #2 template struct B<A<int>>; ``` Prior to P0522, `#2` was picked. Afterwards, this became ambiguous. This patch restores the pre-P0522 behavior, `#2` is picked again.
kadircet
pushed a commit
that referenced
this pull request
Sep 26, 2024
…ap (llvm#108825) This attempts to improve user-experience when LLDB stops on a verbose_trap. Currently if a `__builtin_verbose_trap` triggers, we display the first frame above the call to the verbose_trap. So in the newly added test case, we would've previously stopped here: ``` (lldb) run Process 28095 launched: '/Users/michaelbuch/a.out' (arm64) Process 28095 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: out-of-bounds access frame #1: 0x0000000100003f5c a.out`std::__1::vector<int>::operator[](this=0x000000016fdfebef size=0, (null)=10) at verbose_trap.cpp:6:9 3 template <typename T> 4 struct vector { 5 void operator[](unsigned) { -> 6 __builtin_verbose_trap("Bounds error", "out-of-bounds access"); 7 } 8 }; ``` After this patch, we would stop in the first non-`std` frame: ``` (lldb) run Process 27843 launched: '/Users/michaelbuch/a.out' (arm64) Process 27843 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = Bounds error: out-of-bounds access frame #2: 0x0000000100003f44 a.out`g() at verbose_trap.cpp:14:5 11 12 void g() { 13 std::vector<int> v; -> 14 v[10]; 15 } 16 ``` rdar://134490328
kadircet
pushed a commit
that referenced
this pull request
Oct 16, 2024
…1409)" This reverts commit a89e016. This is being reverted because it broke the test: Unwind/trap_frame_sym_ctx.test /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input CHECK: frame #2: {{.*}}`main
kadircet
pushed a commit
that referenced
this pull request
Nov 1, 2024
…ates explicitly specialized for an implicitly instantiated class template specialization (llvm#113464) Consider the following: ``` template<typename T> struct A { template<typename U> struct B { static constexpr int x = 0; // #1 }; template<typename U> struct B<U*> { static constexpr int x = 1; // #2 }; }; template<> template<typename U> struct A<long>::B { static constexpr int x = 2; // llvm#3 }; static_assert(A<short>::B<int>::y == 0); // uses #1 static_assert(A<short>::B<int*>::y == 1); // uses #2 static_assert(A<long>::B<int>::y == 2); // uses llvm#3 static_assert(A<long>::B<int*>::y == 2); // uses llvm#3 ``` According to [temp.spec.partial.member] p2: > If the primary member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the partial specializations of the member template are ignored for this specialization of the enclosing class template. If a partial specialization of the member template is explicitly specialized for a given (implicit) specialization of the enclosing class template, the primary member template and its other partial specializations are still considered for this specialization of the enclosing class template. The example above fails to compile because we currently don't implement [temp.spec.partial.member] p2. This patch implements the wording, fixing llvm#51051.
kadircet
pushed a commit
that referenced
this pull request
Nov 19, 2024
…onger cause a crash (llvm#116569) This PR fixes a bug introduced by llvm#110199, which causes any half float argument to crash the compiler on MIPS64. Currently compiling this bit of code with `llc -mtriple=mips64`: ``` define void @half_args(half %a) nounwind { entry: ret void } ``` Crashes with the following log: ``` LLVM ERROR: unable to allocate function argument #0 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: llc -mtriple=mips64 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@half_args' #0 0x000055a3a4013df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32d0df8) #1 0x000055a3a401199e llvm::sys::RunSignalHandlers() (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x32ce99e) #2 0x000055a3a40144a8 SignalHandler(int) Signals.cpp:0:0 llvm#3 0x00007f00bde558c0 __restore_rt libc_sigaction.c:0:0 llvm#4 0x00007f00bdea462c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 llvm#5 0x00007f00bde55822 gsignal ./signal/../sysdeps/posix/raise.c:27:6 llvm#6 0x00007f00bde3e4af abort ./stdlib/abort.c:81:7 llvm#7 0x000055a3a3f80e3c llvm::report_fatal_error(llvm::Twine const&, bool) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x323de3c) llvm#8 0x000055a3a2e20dfa (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x20dddfa) llvm#9 0x000055a3a2a34e20 llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const MipsISelLowering.cpp:0:0 llvm#10 0x000055a3a3d896a9 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30466a9) llvm#11 0x000055a3a3e0b3ec llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c83ec) llvm#12 0x000055a3a3e09e21 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c6e21) llvm#13 0x000055a3a2aae1ca llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) MipsISelDAGToDAG.cpp:0:0 llvm#14 0x000055a3a3e07706 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x30c4706) llvm#15 0x000055a3a3051ed6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x230eed6) llvm#16 0x000055a3a35a3ec9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x2860ec9) llvm#17 0x000055a3a35ac3b2 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x28693b2) llvm#18 0x000055a3a35a499c llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x286199c) llvm#19 0x000055a3a262abbb main (/home/davide/Ps2/rps2-tools/prefix/bin/llc+0x18e7bbb) llvm#20 0x00007f00bde3fc4c __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 llvm#21 0x00007f00bde3fd05 call_init ./csu/../csu/libc-start.c:128:20 llvm#22 0x00007f00bde3fd05 __libc_start_main@GLIBC_2.2.5 ./csu/../csu/libc-start.c:347:5 llvm#23 0x000055a3a2624921 _start /builddir/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0 ``` This is caused by the fact that after the change, `f16`s are no longer lowered as `f32`s in calls. Two possible fixes are available: - Update calling conventions to properly support passing `f16` as integers. - Update `useFPRegsForHalfType()` to return `true` so that `f16` are still kept in `f32` registers, as before llvm#110199. This PR implements the first solution to not introduce any more ABI changes as llvm#110199 already did. As of what is the correct ABI for halfs, I don't think there is a correct answer. GCC doesn't support halfs on MIPS, and I couldn't find any information on old MIPS ABI manuals either.
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…#116656) The main issue to solve is that OpenMP modifiers can be specified in any order, so the parser cannot expect any specific modifier at a given position. To solve that, define modifier to be a union of all allowable specific modifiers for a given clause. Additionally, implement modifier descriptors: for each modifier the corresponding descriptor contains a set of properties of the modifier that allow a common set of semantic checks. Start with the syntactic properties defined in the spec: Required, Unique, Exclusive, Ultimate, and implement common checks to verify each of them. OpenMP modifier overhaul: #2/3
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…plementation (llvm#108413. llvm#117704) (llvm#117894) Relands llvm#117704, which relanded changes from llvm#108413 - this was reverted due to build issues. The new offload library did not build with `LIBOMPTARGET_OMPT_SUPPORT` enabled, which was not picked up by pre-merge testing. The last commit contains the fix; everything else is otherwise identical to the approved PR. ___ ### New API Previous discussions at the LLVM/Offload meeting have brought up the need for a new API for exposing the functionality of the plugins. This change introduces a very small subset of a new API, which is primarily for testing the offload tooling and demonstrating how a new API can fit into the existing code base without being too disruptive. Exact designs for these entry points and future additions can be worked out over time. The new API does however introduce the bare minimum functionality to implement device discovery for Unified Runtime and SYCL. This means that the `urinfo` and `sycl-ls` tools can be used on top of Offload. A (rough) implementation of a Unified Runtime adapter (aka plugin) for Offload is available [here](https://github.com/callumfare/unified-runtime/tree/offload_adapter). Our intention is to maintain this and use it to implement and test Offload API changes with SYCL. ### Demoing the new API ```sh # From the runtime build directory $ ninja LibomptUnitTests $ OFFLOAD_TRACE=1 ./offload/unittests/OffloadAPI/offload.unittests ``` ### Open questions and future work * Only some of the available device info is exposed, and not all the possible device queries needed for SYCL are implemented by the plugins. A sensible next step would be to refactor and extend the existing device info queries in the plugins. The existing info queries are all strings, but the new API introduces the ability to return any arbitrary type. * It may be sensible at some point for the plugins to implement the new API directly, and the higher level code on top of it could be made generic, but this is more of a long-term possibility.
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…abort (llvm#117603) Hey guys, I found that Flang's built-in ABORT function is incomplete when I was using it. Compared with gfortran's ABORT (which can both abort and print out a backtrace), flang's ABORT implementation lacks the function of printing out a backtrace. This feature is essential for debugging and understanding the call stack at the failure point. To solve this problem, I completed the "// TODO:" of the abort function, and then implemented an additional built-in function BACKTRACE for flang. After a brief reading of the relevant source code, I used backtrace and backtrace_symbols in "execinfo.h" to quickly implement this. But since I used the above two functions directly, my implementation is slightly different from gfortran's implementation (in the output, the function call stack before main is additionally output, and the function line number is missing). In addition, since I used the above two functions, I did not need to add -g to embed debug information into the ELF file, but needed -rdynamic to ensure that the symbols are added to the dynamic symbol table (so that the function name will be printed out). Here is a comparison of the output between gfortran 's backtrace and my implementation: gfortran's implemention output: ``` #0 0x557eb71f4184 in testfun2_ at /home/hunter/plct/fortran/test.f90:5 #1 0x557eb71f4165 in testfun1_ at /home/hunter/plct/fortran/test.f90:13 #2 0x557eb71f4192 in test_backtrace at /home/hunter/plct/fortran/test.f90:17 llvm#3 0x557eb71f41ce in main at /home/hunter/plct/fortran/test.f90:18 ``` my impelmention output: ``` Backtrace: #0 ./test(_FortranABacktrace+0x32) [0x574f07efcf92] #1 ./test(testfun2_+0x14) [0x574f07efc7b4] #2 ./test(testfun1_+0xd) [0x574f07efc7cd] llvm#3 ./test(_QQmain+0x9) [0x574f07efc7e9] llvm#4 ./test(main+0x12) [0x574f07efc802] llvm#5 /usr/lib/libc.so.6(+0x25e08) [0x76954694fe08] llvm#6 /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x76954694fecc] llvm#7 ./test(_start+0x25) [0x574f07efc6c5] ``` test program is: ``` function testfun2() result(err) implicit none integer :: err err = 1 call backtrace end function testfun2 subroutine testfun1() implicit none integer :: err integer :: testfun2 err = testfun2() end subroutine testfun1 program test_backtrace call testfun1() end program test_backtrace ``` I am well aware of the importance of line numbers, so I am now working on implementing line numbers (by parsing DWARF information) and supporting cross-platform (Windows) support.
kadircet
pushed a commit
that referenced
this pull request
Dec 3, 2024
…w API implementation (llvm#108413. llvm#117704)" (llvm#117995) Reverts llvm#117894 Buildbot failures in OpenMP/Offload bots. https://lab.llvm.org/buildbot/#/builders/30/builds/11193
kadircet
added a commit
that referenced
this pull request
Dec 3, 2024
following ASAN failure is fixed with this patch. We store cleanups in EvalInfo, which are usually run with certain ScopeRAII objects. We can have temporaries in the cleanup stack, backed by CallStackFrame. If such temporaries aren't destroyed before the enclosing CallStackFrame, we end up accessing the freed temporary to run the cleanup. ``` ================================================================= ==553356==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c63f05a65b0 at pc 0x561e4add6ae7 bp 0x7fff430f7770 sp 0x7fff430f7768 READ of size 4 at 0x7c63f05a65b0 thread T0 #0 0x561e4add6ae6 in clang::APValue::operator=(clang::APValue&&) third_party/llvm/llvm-project/clang/lib/AST/APValue.cpp:394:9 #1 0x561e4b41fd0b in (anonymous namespace)::Cleanup::endLifetime((anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:749:27 #2 0x561e4b4d42a7 in (anonymous namespace)::ScopeRAII<((anonymous namespace)::ScopeKind)1>::cleanup((anonymous namespace)::EvalInfo&, bool, unsigned int) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1449:41 llvm#3 0x561e4b4246ec in destroy third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1427:17 llvm#4 0x561e4b4246ec in ~ScopeRAII third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1433:9 llvm#5 0x561e4b4246ec in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5185:1 llvm#6 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#7 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#8 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#9 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#10 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#11 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#12 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#13 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#14 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#15 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#16 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#17 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#18 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#19 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#20 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#21 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#22 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#23 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#24 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#25 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#26 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#27 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#28 0x561e4b4ad3c2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#29 0x561e4b4ad3c2 in (anonymous namespace)::IntExprEvaluator::VisitCastExpr(clang::CastExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14877:10 llvm#30 0x561e4b49f192 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#31 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#32 0x561e4b4a0dd2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#33 0x561e4b4a0dd2 in (anonymous namespace)::IntExprEvaluator::VisitUnaryOperator(clang::UnaryOperator const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14795:10 llvm#34 0x561e4b49f0db in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#35 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#36 0x561e4b3fbe35 in EvaluateAsRValue((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16455:8 llvm#37 0x561e4b3fc278 in clang::Expr::EvaluateForOverflow(clang::ASTContext const&) const third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16903:11 llvm#38 0x561e4a020e69 in clang::Sema::CheckForIntOverflow(clang::Expr const*) third_party/crosstool/v18/stable/src/libcxx/include/__memory/uninitialized_algorithms.h llvm#39 0x561e4a021cd7 in clang::Sema::CheckCompletedExpr(clang::Expr*, clang::SourceLocation, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaChecking.cpp:12989:5 llvm#40 0x561e4a4b9d2e in clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaExprCXX.cpp:9225:3 llvm#41 0x561e4a372e20 in MakeFullExpr third_party/llvm/llvm-project/clang/include/clang/Sema/Sema.h:7292:9 llvm#42 0x561e4a372e20 in clang::Sema::ActOnCondition(clang::Scope*, clang::SourceLocation, clang::Expr*, clang::Sema::ConditionKind, bool) third_party/llvm/llvm-project/clang/lib/Sema/SemaExpr.cpp:20363:26 llvm#43 0x561e49b5407d in clang::Parser::ParseCXXCondition(clang::ActionResult<clang::Stmt*, true>*, clang::SourceLocation, clang::Sema::ConditionKind, bool, clang::Parser::ForRangeInfo*, bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseExprCXX.cpp:2204:20 llvm#44 0x561e49c000a8 in clang::Parser::ParseParenExprOrCondition(clang::ActionResult<clang::Stmt*, true>*, clang::Sema::ConditionResult&, clang::SourceLocation, clang::Sema::ConditionKind, clang::SourceLocation&, clang::SourceLocation&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1376:12 llvm#45 0x561e49bf6c2f in clang::Parser::ParseIfStatement(clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1587:9 llvm#46 0x561e49bf2d6d in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:325:12 llvm#47 0x561e49bf0a6e in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:125:20 llvm#48 0x561e49bff57d in clang::Parser::ParseCompoundStatementBody(bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:1267:11 llvm#49 0x561e49c0136e in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) third_party/llvm/llvm-project/clang/lib/Parse/ParseStmt.cpp:2577:21 llvm#50 0x561e49afa4fd in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1520:10 llvm#51 0x561e49ba6e44 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2460:17 llvm#52 0x561e49af8746 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1244:10 llvm#53 0x561e49af79f8 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1266:12 llvm#54 0x561e49af5d96 in clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:1069:14 llvm#55 0x561e49b6c42c in clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:276:7 llvm#56 0x561e49b6c5d7 in clang::Parser::ParseInnerNamespace(llvm::SmallVector<clang::Parser::InnerNamespaceInfo, 4u> const&, unsigned int, clang::SourceLocation&, clang::ParsedAttributes&, clang::BalancedDelimiterTracker&) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:298:3 llvm#57 0x561e49b6b7c3 in clang::Parser::ParseNamespace(clang::DeclaratorContext, clang::SourceLocation&, clang::SourceLocation) third_party/llvm/llvm-project/clang/lib/Parse/ParseDeclCXX.cpp:253:3 llvm#58 0x561e49ba337a in clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) third_party/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp llvm#59 0x561e49af563a in clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:985:14 llvm#60 0x561e49af3779 in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) third_party/llvm/llvm-project/clang/lib/Parse/Parser.cpp:758:12 llvm#61 0x561e49aec6ae in clang::ParseAST(clang::Sema&, bool, bool) third_party/llvm/llvm-project/clang/lib/Parse/ParseAST.cpp:171:20 llvm#62 0x561e496f13ae in clang::ASTFrontendAction::ExecuteAction() third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1191:3 llvm#63 0x561e496f0874 in clang::FrontendAction::Execute() third_party/llvm/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1077:8 llvm#64 0x561e49644511 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) third_party/llvm/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1062:33 llvm#65 0x561e47ffe1b9 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) third_party/llvm/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:296:25 llvm#66 0x561e47fee631 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) third_party/llvm/llvm-project/clang/tools/driver/cc1_main.cpp:286:15 llvm#67 0x561e47fe9912 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:218:12 llvm#68 0x561e47fec7e6 in operator() third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:360:14 llvm#69 0x561e47fec7e6 in int llvm::function_ref<int (llvm::SmallVectorImpl<char const*>&)>::callback_fn<clang_main(int, char**, llvm::ToolContext const&)::$_0>(long, llvm::SmallVectorImpl<char const*>&) third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 #70 0x561e498bc531 in operator() third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 llvm#71 0x561e498bc531 in operator() third_party/llvm/llvm-project/clang/lib/Driver/Job.cpp:437:34 llvm#72 0x561e498bc531 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__u::optional<llvm::StringRef>>, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>*, bool*) const::$_0>(long) third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 llvm#73 0x561e4ff969e8 in operator() third_party/llvm/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:69:12 llvm#74 0x561e4ff969e8 in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) third_party/llvm/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 llvm#75 0x561e498bb331 in clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__u::optional<llvm::StringRef>>, std::__u::basic_string<char, std::__u::char_traits<char>, std::__u::allocator<char>>*, bool*) const third_party/llvm/llvm-project/clang/lib/Driver/Job.cpp:437:12 llvm#76 0x561e49860e38 in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const third_party/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:196:15 llvm#77 0x561e49861154 in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__u::pair<int, clang::driver::Command const*>>&, bool) const third_party/llvm/llvm-project/clang/lib/Driver/Compilation.cpp:250:19 llvm#78 0x561e49886037 in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__u::pair<int, clang::driver::Command const*>>&) third_party/llvm/llvm-project/clang/lib/Driver/Driver.cpp:1968:5 llvm#79 0x561e47fe8c7d in clang_main(int, char**, llvm::ToolContext const&) third_party/llvm/llvm-project/clang/tools/driver/driver.cpp:396:21 llvm#80 0x561e47fe6ae7 in main blaze-out/k8-opt-asan/bin/third_party/llvm/llvm-project/clang/clang-driver.cpp:17:10 llvm#81 0x7fb3f13c33d3 in __libc_start_main (/usr/grte/v5/lib64/libc.so.6+0x613d3) (BuildId: 9a996398ce14a94560b0c642eb4f6e94) llvm#82 0x561e47f0a229 in _start /usr/grte/v5/debug-src/src/csu/../sysdeps/x86_64/start.S:120 0x7c63f05a65b0 is located 48 bytes inside of 104-byte region [0x7c63f05a6580,0x7c63f05a65e8) freed by thread T0 here: #0 0x561e47fe5342 in operator delete(void*, unsigned long) third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:155:3 #1 0x561e4b4c2fcc in __libcpp_operator_delete<void *, unsigned long> third_party/crosstool/v18/stable/src/libcxx/include/new:286:3 #2 0x561e4b4c2fcc in __do_deallocate_handle_size<> third_party/crosstool/v18/stable/src/libcxx/include/new:310:10 llvm#3 0x561e4b4c2fcc in __libcpp_deallocate third_party/crosstool/v18/stable/src/libcxx/include/new:323:12 llvm#4 0x561e4b4c2fcc in deallocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator.h:135:7 llvm#5 0x561e4b4c2fcc in deallocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator_traits.h:313:9 llvm#6 0x561e4b4c2fcc in std::__u::__tree<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__map_value_compare<std::__u::pair<void const*, unsigned int>, std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::less<std::__u::pair<void const*, unsigned int>>, true>, std::__u::allocator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>>>::destroy(std::__u::__tree_node<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, void*>*) third_party/crosstool/v18/stable/src/libcxx/include/__tree:1549:5 llvm#7 0x561e4b400340 in ~__tree third_party/crosstool/v18/stable/src/libcxx/include/__tree:1539:3 llvm#8 0x561e4b400340 in ~map third_party/crosstool/v18/stable/src/libcxx/include/map:1138:112 llvm#9 0x561e4b400340 in (anonymous namespace)::CallStackFrame::~CallStackFrame() third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1524:1 llvm#10 0x561e4b49697b in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6742:1 llvm#11 0x561e4b400cca in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef<clang::Expr const*>, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6753:10 llvm#12 0x561e4b45cfae in (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10792:10 llvm#13 0x561e4b45dae7 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::RecordExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#14 0x561e4b3f963e in EvaluateRecord third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10917:50 llvm#15 0x561e4b3f963e in EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16425:14 llvm#16 0x561e4b3ff0b3 in EvaluateCallArg(clang::ParmVarDecl const*, clang::Expr const*, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6403:8 llvm#17 0x561e4b440530 in EvaluateArgs(llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, clang::FunctionDecl const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6442:10 llvm#18 0x561e4b4a503e in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8298:12 llvm#19 0x561e4b4a503e in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#20 0x561e4b4a503e in (anonymous namespace)::IntExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:12700:33 llvm#21 0x561e4b49f1a5 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#22 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#23 0x561e4b424658 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#24 0x561e4b424658 in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5182:8 llvm#25 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#26 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#27 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#28 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#29 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#30 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#31 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#32 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#33 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#34 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#35 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#36 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#37 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#38 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#39 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#40 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#41 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#42 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#43 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#44 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#45 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#46 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#47 0x561e4b4ad3c2 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#48 0x561e4b4ad3c2 in (anonymous namespace)::IntExprEvaluator::VisitCastExpr(clang::CastExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:14877:10 llvm#49 0x561e4b49f192 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h previously allocated by thread T0 here: #0 0x561e47fe46bd in operator new(unsigned long) third_party/llvm/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:86:3 #1 0x561e4b424d00 in __libcpp_operator_new<unsigned long> third_party/crosstool/v18/stable/src/libcxx/include/new:277:10 #2 0x561e4b424d00 in __libcpp_allocate third_party/crosstool/v18/stable/src/libcxx/include/new:301:10 llvm#3 0x561e4b424d00 in allocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator.h:120:32 llvm#4 0x561e4b424d00 in allocate third_party/crosstool/v18/stable/src/libcxx/include/__memory/allocator_traits.h:281:16 llvm#5 0x561e4b424d00 in __construct_node<const std::__u::piecewise_construct_t &, std::__u::tuple<std::__u::pair<const void *, unsigned int> &&>, std::__u::tuple<> > third_party/crosstool/v18/stable/src/libcxx/include/__tree:1820:21 llvm#6 0x561e4b424d00 in std::__u::pair<std::__u::__tree_iterator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__tree_node<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, void*>*, long>, bool> std::__u::__tree<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::__map_value_compare<std::__u::pair<void const*, unsigned int>, std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>, std::__u::less<std::__u::pair<void const*, unsigned int>>, true>, std::__u::allocator<std::__u::__value_type<std::__u::pair<void const*, unsigned int>, clang::APValue>>>::__emplace_unique_key_args<std::__u::pair<void const*, unsigned int>, std::__u::piecewise_construct_t const&, std::__u::tuple<std::__u::pair<void const*, unsigned int>&&>, std::__u::tuple<>>(std::__u::pair<void const*, unsigned int> const&, std::__u::piecewise_construct_t const&, std::__u::tuple<std::__u::pair<void const*, unsigned int>&&>&&, std::__u::tuple<>&&) third_party/crosstool/v18/stable/src/libcxx/include/__tree:1787:25 llvm#7 0x561e4b424a03 in operator[] third_party/crosstool/v18/stable/src/libcxx/include/map:1531:8 llvm#8 0x561e4b424a03 in (anonymous namespace)::CallStackFrame::createLocal(clang::APValue::LValueBase, void const*, clang::QualType, (anonymous namespace)::ScopeKind) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1963:21 llvm#9 0x561e4b42bd95 in clang::APValue& (anonymous namespace)::CallStackFrame::createTemporary<clang::Expr>(clang::Expr const*, clang::QualType, (anonymous namespace)::ScopeKind, (anonymous namespace)::LValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:1944:10 llvm#10 0x561e4b3ffd17 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16367:27 llvm#11 0x561e4b40429c in handleLValueToRValueConversion((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::QualType, (anonymous namespace)::LValue const&, clang::APValue&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:4518:12 llvm#12 0x561e4b496e9c in handleTrivialCopy((anonymous namespace)::EvalInfo&, clang::ParmVarDecl const*, clang::Expr const*, clang::APValue&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6469:10 llvm#13 0x561e4b494fdd in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6582:12 llvm#14 0x561e4b400cca in HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef<clang::Expr const*>, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6753:10 llvm#15 0x561e4b45cfae in (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10792:10 llvm#16 0x561e4b45dae7 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::RecordExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#17 0x561e4b3f963e in EvaluateRecord third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:10917:50 llvm#18 0x561e4b3f963e in EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16425:14 llvm#19 0x561e4b3ff0b3 in EvaluateCallArg(clang::ParmVarDecl const*, clang::Expr const*, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6403:8 llvm#20 0x561e4b440530 in EvaluateArgs(llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, clang::FunctionDecl const*, bool) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6442:10 llvm#21 0x561e4b4a503e in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8298:12 llvm#22 0x561e4b4a503e in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#23 0x561e4b4a503e in (anonymous namespace)::IntExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:12700:33 llvm#24 0x561e4b49f1a5 in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::IntExprEvaluator, bool>::Visit(clang::Stmt const*) third_party/llvm/llvm-project/clang/include/clang/AST/StmtVisitor.h llvm#25 0x561e4b3ff8af in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16339:41 llvm#26 0x561e4b424658 in EvaluateAsBooleanCondition third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:2742:8 llvm#27 0x561e4b424658 in EvaluateCond((anonymous namespace)::EvalInfo&, clang::VarDecl const*, clang::Expr const*, bool&) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5182:8 llvm#28 0x561e4b41ea8c in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5555:17 llvm#29 0x561e4b423755 in EvaluateLoopBody((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5221:24 llvm#30 0x561e4b41d597 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5635:28 llvm#31 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#32 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#33 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#34 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#35 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#36 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 llvm#37 0x561e4b4c3e5b in clang::StmtVisitorBase<llvm::make_const_ptr, (anonymous namespace)::PointerExprEvaluator, bool>::Visit(clang::Stmt const*) blaze-out/k8-opt-asan/genfiles/third_party/llvm/llvm-project/clang/include/clang/AST/StmtNodes.inc llvm#38 0x561e4b3ff820 in EvaluatePointer third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9458:60 llvm#39 0x561e4b3ff820 in Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:16343:10 llvm#40 0x561e4b41f204 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5511:17 llvm#41 0x561e4b41d341 in EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:5521:28 llvm#42 0x561e4b40113c in HandleFunctionCall(clang::SourceLocation, clang::FunctionDecl const*, (anonymous namespace)::LValue const*, clang::Expr const*, llvm::ArrayRef<clang::Expr const*>, (anonymous namespace)::CallRef, clang::Stmt const*, (anonymous namespace)::EvalInfo&, clang::APValue&, (anonymous namespace)::LValue const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:6520:24 llvm#43 0x561e4b4c9652 in handleCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8332:10 llvm#44 0x561e4b4c9652 in VisitCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:8132:10 llvm#45 0x561e4b4c9652 in visitNonBuiltinCallExpr third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9749:28 llvm#46 0x561e4b4c9652 in (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) third_party/llvm/llvm-project/clang/lib/AST/ExprConstant.cpp:9763:12 ```
kadircet
pushed a commit
that referenced
this pull request
Dec 6, 2024
…ne symbol size as symbols are created (llvm#117079)" This reverts commit ba668eb. Below test started failing again on x86_64 macOS CI. We're unsure if this patch is the exact cause, but since this patch has broken this test before, we speculatively revert it to see if it was indeed the root cause. ``` FAIL: lldb-shell :: Unwind/trap_frame_sym_ctx.test (1692 of 2162) ******************** TEST 'lldb-shell :: Unwind/trap_frame_sym_ctx.test' FAILED ******************** Exit Code: 1 Command Output (stderr): -- RUN: at line 7: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp clang: warning: argument unused during compilation: '-fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument] RUN: at line 8: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit | /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit + /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input ^ <stdin>:26:64: note: scanning from here frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp ^ <stdin>:27:2: note: possible intended match here frame #2: 0x00007ff7bfeff6c0 ^ Input file: <stdin> Check file: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -dump-input=help explains the following input dump. Input was: <<<<<< . . . 21: 0x100003ed1 <+0>: pushq %rbp 22: 0x100003ed2 <+1>: movq %rsp, %rbp 23: (lldb) thread backtrace -u 24: * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 25: * frame #0: 0x0000000100003ecc trap_frame_sym_ctx.test.tmp`bar 26: frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp check:21'0 X error: no match found 27: frame #2: 0x00007ff7bfeff6c0 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:21'1 ? possible intended match 28: frame llvm#3: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 29: frame llvm#4: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 30: frame llvm#5: 0x00007ff8193cc41f dyld`start + 1903 check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: (lldb) exit check:21'0 ~~~~~~~~~~~~ >>>>>> ```
kadircet
pushed a commit
that referenced
this pull request
Dec 6, 2024
## Description This PR fixes a segmentation fault that occurs when passing options requiring arguments via `-Xopenmp-target=<triple>`. The issue was that the function `Driver::getOffloadArchs` did not properly parse the extracted option, but instead assumed it was valid, leading to a crash when incomplete arguments were provided. ## Backtrace ```sh llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: llvm-project/build/bin/clang++ main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -Xopenmp-target=powerpc64le-ibm-linux-gnu -o 1. Compilation construction 2. Building compilation actions #0 0x0000562fb21c363b llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (llvm-project/build/bin/clang+++0x392f63b) #1 0x0000562fb21c0e3c SignalHandler(int) Signals.cpp:0:0 #2 0x00007fcbf6c81420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) llvm#3 0x0000562fb1fa5d70 llvm::opt::Option::matches(llvm::opt::OptSpecifier) const (llvm-project/build/bin/clang+++0x3711d70) llvm#4 0x0000562fb2a78e7d clang::driver::Driver::getOffloadArchs(clang::driver::Compilation&, llvm::opt::DerivedArgList const&, clang::driver::Action::OffloadKind, clang::driver::ToolChain const*, bool) const (llvm-project/build/bin/clang+++0x41e4e7d) llvm#5 0x0000562fb2a7a9aa clang::driver::Driver::BuildOffloadingActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, std::pair<clang::driver::types::ID, llvm::opt::Arg const*> const&, clang::driver::Action*) const (.part.1164) Driver.cpp:0:0 llvm#6 0x0000562fb2a7c093 clang::driver::Driver::BuildActions(clang::driver::Compilation&, llvm::opt::DerivedArgList&, llvm::SmallVector<std::pair<clang::driver::types::ID, llvm::opt::Arg const*>, 16u> const&, llvm::SmallVector<clang::driver::Action*, 3u>&) const (llvm-project/build/bin/clang+++0x41e8093) llvm#7 0x0000562fb2a8395d clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (llvm-project/build/bin/clang+++0x41ef95d) llvm#8 0x0000562faf92684c clang_main(int, char**, llvm::ToolContext const&) (llvm-project/build/bin/clang+++0x109284c) llvm#9 0x0000562faf826cc6 main (llvm-project/build/bin/clang+++0xf92cc6) llvm#10 0x00007fcbf6699083 __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:342:3 llvm#11 0x0000562faf923a5e _start (llvm-project/build/bin/clang+++0x108fa5e) [1] 2628042 segmentation fault (core dumped) main.cpp -fopenmp=libomp -fopenmp-targets=powerpc64le-ibm-linux-gnu -o ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most of the time the included-header cannot be just
#include
d fromuser code, and providing findings asking for the inclusion of the inner
header seems wrong.
We have enough explicit intent from the developer around included header
and including header being related via use of include_next directive,
instead of a regular include.
So this patch proposes to treat the inner header as being exported so
that the user can only include the outer header. This also works nicely
when the user is transitively relying on inner header, we'll still
suggest including that one and if the spelling of inner and outer
headers are different that inclusion will be correct. Otherwise if the
spellings are the same, we'll treat the outer header as the provider.