[llvm-bugs] [Bug 125178] [clang-format] QualifierAlignment/QualifierOrder leads to broken code when using qualified names
Issue
125178
Summary
[clang-format] QualifierAlignment/QualifierOrder leads to broken code when using qualified names
Labels
clang-format,
invalid-code-generation
Assignees
Reporter
carlosgalvezp
Example input:
```cpp
#include
std::int64_t constexpr x{123};
```
Run:
```
$ clang-format --style="{QualifierAlignment: Custom, QualifierOrder:[constexpr, type,const]}" file.cpp
```
Output:
```
#include
std::constexpr int64_t x{123};
```
Repro: https://godbolt.org/z/Tdx4TeMoc
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125177] clang allows invalid unicode escapes in identifiers (only after first character)
Issue 125177 Summary clang allows invalid unicode escapes in identifiers (only after first character) Labels clang Assignees Reporter mrolle45 The clang lexer, after seeing an ASCII identifier starting character, uses `LexIdentifierContinue()` to get the rest of the token. If it sees a \u or \U escape, it consumes this as the next character in the identifier. However, **it does not check if this is a valid unicode continuation character.** To demonstrate this, I wrote some lines which try to #define the identifier as a macro, and then see if this succeeds by invoking the macro. I used a number of invalid unicode characters, including surrogate codepoints and codepoints above the maximum allowed value. I included one valid unicode character, \u03b4. I also tested the unicode characters without the leading ascii characters, and clang correctly does not recognize the invalid ones as identifiers Here is the demo program and the result of invoking `clang -E`. ```c #define X\u00B0() X\u00B0 is an identifier. X\u00B0() #define X\u03B4() X\u03B4 is an identifier. X\u03B4() #define X\uD800() X\uD800 is an identifier. X\u00B0() #define X\U1000() X\U1000 is an identifier. X\U1000() #define \u00B0() \u00B0 is an identifier. \u00B0() #define \u03B4() \u03B4 is an identifier. \u03B4() #define \uD800() \uD800 is an identifier. \u00B0() #define \U1000() \U1000 is an identifier. \U1000() X° is an identifier. -- wrong Xδ is an identifier. X° is an identifier. -- wrong X is an identifier. -- wrong \u00B0() δ is an identifier. \u00B0() \U1000() ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125180] Underlying type of unscoped and unfixed member enumerations of class templates
Issue
125180
Summary
Underlying type of unscoped and unfixed member enumerations of class templates
Labels
new issue
Assignees
Reporter
thebrandre
If compatibility with MSVC is enabled, Clang correctly uses `int` as the underlying type of an unscoped enumeration even if the assigned integer causes an overflow - at least at namespace scope. This is correct in the sense of compatibility, which is officially documented by Microsoft [here](https://learn.microsoft.com/en-us/cpp/build/reference/zc-enumtypes?view=msvc-170).
However, if the same declaration appears inside a class template, `-fms-compatibility` is not honored.
```cpp
template
struct S {
enum E { X, Y = 0x };
};
enum E { X, Y = 0x };
constexpr bool check(int) { return true; }
constexpr bool check(unsigned int) { return false; }
static_assert(check(E::X), ""); // succeeds
static_assert(check(S::E::X), ""); // fails
```
See here on Compiler Explorer: https://godbolt.org/z/Ge8qehE5P
I am aware that there are a lot of open issues on the underlying type of enumerations when using `-fms-compatibility` (#120759 #122032 #1883 to name a few) but this one should be orthogonal.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125152] [flang] llvm 20 branch build broken on Windows
Issue
125152
Summary
[flang] llvm 20 branch build broken on Windows
Labels
flang
Assignees
Reporter
songdongsheng
It can be confirmed that there is no problem in version https://github.com/llvm/llvm-project/commit/6087c3049656bbaef51fffb48e2404e86f7e0d3f . However, I don't have time to run 'git blame' to confirm that the problem occurred in that version.
First build clang and lld using MSVC:
```bash
-DLLVM_ENABLE_PROJECTS="clang;lld" ^
-DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx" ^
```
Use the built clang and lld to build more projects:
```bash
-DLLVM_ENABLE_PROJECTS="llvm;clang;clang-tools-extra;openmp;lld;lldb;polly;mlir;flang" ^
-DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx" ^
```
Then there is an error when building flang runtime:
```bash
E:\var\vcs\llvm-project-build_20.0.0-20250129\build64>ninja -j 1
[0/20] Performing build step for 'builtins'ninja: no work to do.
[1/20] No install step for 'builtins'
[4/20] Building CXX object tools\flang\runtime\CMakeFiles\FortranRuntime.static.dir\exceptions.cpp.obj
FAILED: tools/flang/runtime/CMakeFiles/FortranRuntime.static.dir/exceptions.cpp.obj
E:\var\vcs\llvm-project-build_20.0.0-20250129\build64_stage0\bin\clang-cl.exe /nologo -TP -DFLANG_INCLUDE_TESTS=1 -DFLANG_LITTLE_ENDIAN=1 -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -IE:\var\vcs\llvm-project-build_20.0.0-20250129\build64\tools\flang\runtime -IE:\var\vcs\llvm-project\flang\runtime -IE:\var\vcs\llvm-project\flang\include -IE:\var\vcs\llvm-project-build_20.0.0-20250129\build64\tools\flang\include -IE:\var\vcs\llvm-project-build_20.0.0-20250129\build64\include -IE:\var\vcs\llvm-project\llvm\include -imsvcE:\var\vcs\llvm-project\llvm\..\mlir\include -imsvcE:\var\vcs\llvm-project-build_20.0.0-20250129\build64\tools\mlir\include -imsvcE:\var\vcs\llvm-project-build_20.0.0-20250129\build64\tools\clang\include -imsvcE:\var\vcs\llvm-project\llvm\..\clang\include /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- -Werror=unguarded-availability-new /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported /Gw -Wno-deprecated-copy -Wno-string-conversion -Wno-ctad-maybe-unsupported -fno-lto /O2 /Ob2 /DNDEBUG -std:c++17 -MT -U_GLIBCXX_ASSERTIONS -U_LIBCPP_ENABLE_ASSERTIONS /EHs-c- /GR- /EHs-c- /GR- /EHs-c- /GR- /EHs-c- /GR- /EHs-c- /GR- /showIncludes /Fotools\flang\runtime\CMakeFiles\FortranRuntime.static.dir\exceptions.cpp.obj /Fdtools\flang\runtime\CMakeFiles\FortranRuntime.static.dir\FortranRuntime.static.pdb -c -- E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(48,31): error: use of undeclared identifier '__FE_DENORM'
48 | static constexpr uint32_t s{__FE_DENORM}; // nonstandard, not a #define
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(64,29): error: constexpr variable 'map' must be initialized by a constant _expression_
64 | static constexpr uint32_t map[]{xm};
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(64,35): note: initializer of 's' is unknown
64 | static constexpr uint32_t map[]{xm};
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(62,12): note: expanded from macro 'xm'
62 | #define xm um(0), um(x)
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(61,15): note: expanded from macro 'um'
61 | #define um(p) om(p), om(p | u)
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(60,15): note: expanded from macro 'om'
60 | #define om(p) zm(p), zm(p | o)
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(59,15): note: expanded from macro 'zm'
59 | #define zm(p) sm(p), sm(p | z)
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(58,29): note: expanded from macro 'sm'
58 | #define sm(p) vm(p), vm(p | s)
| ^
E:\var\vcs\llvm-project\flang\runtime\exceptions.cpp(48,29): note: declared here
48 | static constexpr uint32_t s{__FE_DENORM}; // nonstandard, not a #define
| ^
2 errors generated.
ninja: build stopped: subcommand failed.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125154] __riscv_vsetvlmax_e64m1 & co not available with attribute target arch=+v
Issue
125154
Summary
__riscv_vsetvlmax_e64m1 & co not available with attribute target arch=+v
Labels
new issue
Assignees
Reporter
dzaima
Copying out of https://github.com/llvm/llvm-project/issues/56592:
The following fails to compile with `-march=rv64gc`, despite working with `-march=rv64gcv`, which should be what the `__attribute__` achieves:
```
#include
__attribute__((target("arch=+v")))
int vl_e64m1() {
return __riscv_vsetvlmax_e64m1();
}
```
https://godbolt.org/z/rPnh5zYE5
I believe this would be because these definitions are preprocessor-gated: https://github.com/llvm/llvm-project/blob/33c42f8bc5615b4dc46cb45ab41da97be52474ec/clang/include/clang/Basic/riscv_vector.td#L637-L675
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125155] [lld] lld incorrectly marking functions available_externally while linking Destructors with Mixed Comdats
Issue
125155
Summary
[lld] lld incorrectly marking functions available_externally while linking Destructors with Mixed Comdats
Labels
Assignees
Reporter
pranav-159
when compiling the project ZenDNN with LLVM faced an error similar to that of given below
```
Alias must point to a definition
ptr @_ZN1AIiED1Ev
LLVM ERROR: Broken module found, compilation aborted!
```
A simple test case demonstrating the issue:
```
; RUN: rm -rf %t.dir && split-file %s %t.dir && cd %t.dir
; RUN: llvm-as a.ll -o a.bc && llvm-as b.ll -o b.bc
; RUN: ld.lld -shared a.bc b.bc -o out.so
;--- a.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
$_ZN1AIiED0Ev = comdat any
define linkonce_odr void @_ZN1AIiED0Ev(ptr noundef nonnull %this) unnamed_addr comdat {
call void @_ZdlPv(ptr noundef %this)
ret void
}
declare void @_ZdlPv(ptr noundef)
;--- b.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
$_ZN1AIiED5Ev = comdat any
@_ZN1AIiED1Ev = weak_odr unnamed_addr alias void (ptr), ptr @_ZN1AIiED2Ev
define weak_odr void @_ZN1AIiED2Ev(ptr noundef nonnull %this) unnamed_addr comdat($_ZN1AIiED5Ev) {
ret void
}
define weak_odr void @_ZN1AIiED0Ev(ptr noundef nonnull %this) unnamed_addr comdat($_ZN1AIiED5Ev) {
entry:
call void @_ZN1AIiED1Ev(ptr noundef nonnull %this)
call void @_ZdlPv(ptr noundef %this)
ret void
}
declare void @_ZdlPv(ptr noundef)
```
and the C code reproducer:
```
// RUN: split-file %s %t
// RUN: %clang -fPIC -shared -O3 -flto %t/implicit.cpp %t/explicit.cpp
//--- test.h
#include
struct Base {
Base() { std::cout << "Base Constructor\n"; }
virtual ~Base() { std::cout << "Base Destructor\n"; }
};
template
struct Derived : public Base {
Derived() { std::cout << "Derived Constructor\n"; }
~Derived() {};
};
//--- explicit.cpp
#include "test.h"
template struct Derived;
void foo() {
Base* obj = new Derived();
delete obj;
}
//--- implicit.cpp
#include "test.h"
void bar() {
Base* obj = new Derived();
delete obj;
}
```
while analyzing the issue found that opt inlines D2 destructor into D0 destructor in a.ll (implicit instantiation), hence it contains only D0 function in D0 comdat whereas b.ll (explicit instantiation) contains all D0/D1/D2 destructors in D5 comdat.
In this IR with mixed comdats, D0 of a.ll is marked prevailing whereas D0 in b.ll is marked non-prevailing. As lld tries to remove D0 from b.ll and its COMDAT D5 (which is marked as non-prevailing because of D0), it marks D2 as available_externally, even though it is prevailing. Since D1 alias D2, which is not considered as real definition as its linkage type is available_externally, IR-Verifier pass throws the above-mentioned error.
In thinLTO flow this issue not observed, it may be because of this commit [12050a3] (https://github.com/llvm/llvm-project/commit/12050a3fb7344694cfd7527d4cca0033729bcfc5#diff-56a1bc22385a365b144c1ecc9d53128cb8f16dad12cc6f13b8ddf293a6c583b3) and its corresponding test case can be found at llvm/test/ThinLTO/X86/ctor-dtor-alias2.ll .
Can we fix it similarly by not marking its comdat as non-prevailing, if the symbols name and comdat's name doesn't match? thereby leaving other symbols in comdat intact.
```diff
diff --git a/llvm/lib/LTO/LTO.cpp b/llvm/lib/LTO/LTO.cpp
index 0f53c6085121..d66846756842 100644
--- a/llvm/lib/LTO/LTO.cpp
+++ b/llvm/lib/LTO/LTO.cpp
@@ -928,7 +928,7 @@ LTO::addRegularLTO(BitcodeModule BM, ArrayRef Syms,
// module (in linkRegularLTO), based on whether it is undefined.
Mod.Keep.push_back(GV);
GV->setLinkage(GlobalValue::AvailableExternallyLinkage);
-if (GV->hasComdat())
+if (GV->getComdat()->getName() == GV->getName())
NonPrevailingComdats.insert(GV->getComdat());
cast(GV)->setComdat(nullptr);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125165] [Clang] Crash during instantiation of a fold expression that uses an invalid structured-binding pack
Issue
125165
Summary
[Clang] Crash during instantiation of a fold _expression_ that uses an invalid structured-binding pack
Labels
clang:frontend,
crash-on-invalid
Assignees
Reporter
Sirraide
Consider (https://godbolt.org/z/9oWz76GMf):
```c++
template
auto f(auto t) {
const auto& [...pack] = t;
(pack, ...);
};
void g() {
f('x');
}
```
After correctly diagnosing that we can’t decompose `t`, trying to instantiate the fold _expression_ crashes:
```console
clang++: /root/llvm-project/clang/lib/AST/ExprCXX.cpp:1960: clang::CXXFoldExpr::CXXFoldExpr(
clang::QualType, clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr*, clang::BinaryOperatorKind,
clang::SourceLocation, clang::Expr*, clang::SourceLocation, std::optional):
Assertion `((LHS && LHS->containsUnexpandedParameterPack()) != (RHS && RHS->containsUnexpandedParameterPack()))
&& "Exactly one of LHS or RHS should contain an unexpanded pack"' failed.
```
The stack trace is in tree transform, and the crash doesn’t happen if the `t` parameter is not dependent. Full stack trace:
```console
:3:17: error: cannot decompose non-class, non-array type 'char const'
3 | const auto& [...pack] = t;
| ^
:8:5: note: in instantiation of function template specialization 'f' requested here
8 | f('x');
| ^
clang++: /root/llvm-project/clang/lib/AST/ExprCXX.cpp:1960: clang::CXXFoldExpr::CXXFoldExpr(clang::QualType, clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr*, clang::BinaryOperatorKind, clang::SourceLocation, clang::Expr*, clang::SourceLocation, std::optional): Assertion `((LHS && LHS->containsUnexpandedParameterPack()) != (RHS && RHS->containsUnexpandedParameterPack())) && "Exactly one of LHS or RHS should contain an unexpanded pack"' failed.
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: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -fno-verbose-asm -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++26
1. :8:10: current parser token ')'
2. :7:10: parsing function body 'g'
3. :7:10: in compound statement ('{}')
4. :2:6: instantiating function definition 'f'
#0 0x03e422a8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3e422a8)
#1 0x03e3ff64 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3e3ff64)
#2 0x03d8c438 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x70c331a42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x70c331a969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x70c331a42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x70c331a287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x70c331a2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x70c331a39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x07ad32b1 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7ad32b1)
#10 0x07440d37 clang::Sema::BuildCXXFoldExpr(clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr*, clang::BinaryOperatorKind, clang::SourceLocation, clang::Expr*, clang::SourceLocation, std::optional) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x7440d37)
#11 0x07396916 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCXXFoldExpr(clang::CXXFoldExpr*) SemaTemplateInstantiate.cpp:0:0
#12 0x0738120d clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformExpr(clang::Expr*) SemaTemplateInstantiate.cpp:0:0
#13 0x073af157 clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*, clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::StmtDiscardKind) SemaTemplateInstantiate.cpp:0:0
#14 0x073afd4e clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*, bool) SemaTemplateInstantiate.cpp:0:0
#15 0x073b7d44 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x73b7d44)
#16 0x0742d474 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x742d474)
#17 0x0806d171 clang::StackExhaustionHandler::runWithSufficientStackSpace(clang::SourceLocation, llvm::func
[llvm-bugs] [Bug 125167] `clangd` crash while parsing `range/v3/algorithm/nth_element.hpp`
Issue
125167
Summary
`clangd` crash while parsing `range/v3/algorithm/nth_element.hpp`
Labels
new issue
Assignees
Reporter
pierzchalski
Since it asked nicely:
```
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. /**/range-v3/include/range/v3/algorithm/nth_element.hpp:117:44: current parser token ';'
1. /**/range-v3/include/range/v3/algorithm/nth_element.hpp:47:1: parsing namespace 'ranges'
2. /**/range-v3/include/range/v3/algorithm/nth_element.hpp:106:5 : parsing struct/union/class body 'ranges::nth_element_fn'
3. /**/range-v3/include/range/v3/algorithm/nth_element.hpp:113:9: parsing function body 'ranges::nth_element_fn::operator()'
4. /**/range-v3/include/range/v3/algorithm/nth_element.hpp:113:9: in compound statement ('{}')
#0 0x7f530591301c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/nix/store/f582fg8k06z2xg8zlwnrn4g895szwzfp-llvm-19.1.6-lib/lib/libLLVM.so.19.1+0xfee01c)
#1 0x7f530591045b SignalHandler(int) (/nix/store/f582fg8k06z2xg8zlwnrn4g895szwzfp-llvm-19.1.6-lib/lib/libLLVM.so.19.1+0xfeb45b)
#2 0x7f53043d5a70 __restore_rt (/nix/store/h7zcxabfxa7v5xdna45y2hplj31ncf8a-glibc-2.40-36/lib/libc.so.6+0x40a70)
#3 0x7f530fec7c0a clang::Sema::DeclareAggregateDeductionGuideFromInitList(clang::TemplateDecl*, llvm::MutableArrayRef, clang::SourceLocation) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x2119c0a)
#4 0x7f530fae6347 clang::Sema::DeduceTemplateSpecializationFromInitializer(clang::TypeSourceInfo*, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef)::'lambda'(bool)::operator()(bool) const::'lambda'(clang::InitListExpr*)::operator()(clang::InitListExpr*) const (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x1d38347)
#5 0x7f530fae6a75 clang::Sema::DeduceTemplateSpecializationFromInitializer(clang::TypeSourceInfo*, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef)::'lambda'(bool)::operator()(bool) const (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x1d38a75)
#6 0x7f530fae729b clang::Sema::DeduceTemplateSpecializationFromInitializer(clang::TypeSourceInfo*, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x1d3929b)
#7 0x7f530f71940d clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*, clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*, clang::SourceRange, bool, clang::Expr*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x196b40d)
#8 0x7f530f72e12d clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool, clang::Expr*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x198012d)
#9 0x7f530f75a73a clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0x19ac73a)
#10 0x7f530ea8f5d5 clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0xce15d5)
#11 0x7f530eaa4d74 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0xcf6d74)
#12 0x7f530eaa8db7 clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, bool, clang::Parser::ForRangeInit*, clang::SourceLocation*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0xcfadb7)
#13 0x7f530eaa92b3 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0xcfb2b3)
#14 0x7f530eb5b498 clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::ParsedAttributes&, clang::ParsedAttributes&) (/nix/store/ymbp8lmggn7qgb8lwrzyzxnbyz77x08r-clang-19.1.6-lib/lib/libclang-cpp.so.19.1+0xdad498)
#15 0x7f530eb5befa clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedS
[llvm-bugs] [Bug 125164] HeuristicResolver incorrectly applies const-checking to static methods called through an instance
Issue
125164
Summary
HeuristicResolver incorrectly applies const-checking to static methods called through an instance
Labels
new issue
Assignees
HighCommander4
Reporter
HighCommander4
In the following code:
```c++
template
struct Waldo {
static void find();
};
template
void foo(const Waldo& t) {
t.find();
}
```
HeuristicResolver fails to resolve the call to `t.find()` to `Waldo::find()` because it's applying const-checking even though that doesn't apply to static methods (even if you call them through an instance, as in this example).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125123] Invalid IR crashing clang-19.1.7 O3
Issue 125123 Summary Invalid IR crashing clang-19.1.7 O3 Labels new issue Assignees Reporter connorl309 Hi, I have received the following crash and error information from running clang on invalid IR. Is clang supposed to crash on invalid IR? Is this considered to be a bug? opt-verify yields the following error on a generated .ll IR file: ``` PHI node entries do not match predecessors! %0 = phi i32 [ %1, %execute_if ], [ %2, %div ] label %div label %cont opt-19: local2ifelse.ll: error: input module is broken! ``` I recognize that the IR is invalid, but if it is run through clang-19 with the following command: `clang-19 -O3 local2ifelse.ll` I receive the following crashing backtrace: ``` warning: overriding the module target triple with x86_64-pc-linux-gnu [-Woverride-module] 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: /usr/lib/llvm-19/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name local2ifelse.ll -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=none -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/root -fcoverage-compilation-dir=/root -resource-dir /usr/lib/llvm-19/lib/clang/19 -O3 -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -vectorize-loops -vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/local2ifelse-a8a9ae.o -x ir local2ifelse.ll 1. Optimizer 2. Running pass "function(ee-instrument<>,lower-expect,simplifycfg,sroa,early-cse<>,callsite-splitting)" on module "local2ifelse.ll" 3. Running pass "simplifycfg" on function "Main_main" #0 0x7efdaf705876 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xea9876) #1 0x7efdaf703450 llvm::sys::RunSignalHandlers() (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xea7450) #2 0x7efdaf705f3b (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0xea9f3b) #3 0x7efdae334520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7efdb02d9c10 llvm::GetIfCondition(llvm::BasicBlock*, llvm::BasicBlock*&, llvm::BasicBlock*&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1a7dc10) #5 0x7efdb03e98e9 (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1b8d8e9) #6 0x7efdb03e5933 (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1b89933) #7 0x7efdb03e4630 llvm::simplifyCFG(llvm::BasicBlock*, llvm::TargetTransformInfo const&, llvm::DomTreeUpdater*, llvm::SimplifyCFGOptions const&, llvm::ArrayRef) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1b88630) #8 0x7efdb07e6fef (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1f8afef) #9 0x7efdb07e6925 (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1f8a925) #10 0x7efdb07e5862 llvm::SimplifyCFGPass::run(llvm::Function&, llvm::AnalysisManager&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1f89862) #11 0x7efdb0b46bad (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x22eabad) #12 0x7efdaf88c5f9 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x10305f9) #13 0x7efdb18ebc4d (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x308fc4d) #14 0x7efdaf890234 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x1034234) #15 0x7efdb18eba6d (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x308fa6d) #16 0x7efdaf88b3f9 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/usr/lib/llvm-19/bin/../lib/libLLVM.so.19.1+0x102f3f9) #17 0x7efdb825b711 (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1e49711) #18 0x7efdb8253f7b clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x1e41f7b) #19 0x7efdb85ff417 clang::CodeGenAction::ExecuteAction() (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x21ed417) #20 0x7efdb90f8a95 clang::FrontendAction::Execute() (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2ce6a95) #21 0x7efdb9068a34 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/usr/lib/llvm-19/bin/../lib/libclang-cpp.so.19.1+0x2c56a34) #22 0x7efdb9175bee clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/usr/lib/llvm-19/bin/../lib/libcla
[llvm-bugs] [Bug 125112] Request Commit Access For winner245
Issue 125112 Summary Request Commit Access For winner245 Labels infra:commit-access-request Assignees Reporter winner245 ### Why Are you requesting commit access ? I have been actively contributing to libc++ for the past few months, focusing on areas such as bug fixes, performance improvements, and exception safety enhancements for libc++. To facilitate my ongoing and future contributions, I would like to request commit access. Thank you for your consideration! Peng ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125173] how to define an array in mlir?
Issue
125173
Summary
how to define an array in mlir?
Labels
mlir
Assignees
Reporter
Shaquille-Wu
hello, llvm&mlir experts
I have a trouble about defining an array in mlir.
first, I define a Dialect named as lunar, it is very simple dialect like this in .td file:
```
#ifndef LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
#define LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
include "mlir/IR/OpBase.td"
def Lunar_Dialect : Dialect {
let name = "lunar";
let summary = "A dialect for elementwise math";
let description = [{
The lunar dialect defines types and operations for elementwise computation.
}];
let cppNamespace = "::mlir::lunar";
let useDefaultTypePrinterParser = 1;
}
#endif // LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
```
second, I define a datatype named as "array" in another .td file, like this:
```
#ifndef LIB_DIALECT_LUNAR_LUNARTYPES_TD_
#define LIB_DIALECT_LUNAR_LUNARTYPES_TD_
include "LunarDialect.td"
include "mlir/IR/AttrTypeBase.td"
include "mlir/IR/BuiltinTypes.td"
include "mlir/IR/BuiltinTypeInterfaces.td"
// A base class for all types in this dialect
class Lunar_Type traits = []> : TypeDef {
let mnemonic = typeMnemonic;
}
def ArrayData : Lunar_Type<"ArrayData", "array"> {
let summary = "A array data";
let description = [{
A type for array.
}];
let parameters = (ins "Type":$dataType, "int":$size);
let assemblyFormat = [{ `<` $dataType `x` $size `>` }];
}
#endif // LIB_DIALECT_LUNAR_LUNARTYPES_TD_
```
the third, I modify my the .cpp file about LunarDialect like this:
```
#include "LunarDialect.h"
#include "LunarTypes.h"
#include "mlir/IR/Builders.h"
#include "mlir/IR/BuiltinTypes.h"
#include "mlir/IR/DialectImplementation.h"
#include "llvm/ADT/TypeSwitch.h"
#include "Dialect/Lunar/LunarDialect.cpp.inc"
#define GET_TYPEDEF_CLASSES
#include "Dialect/Lunar/LunarTypes.cpp.inc"
namespace mlir {
namespace lunar {
void LunarDialect::initialize() {
addTypes<
#define GET_TYPEDEF_LIST
#include "Dialect/Lunar/LunarTypes.cpp.inc"
>();
}
} // namespace poly
} // namespace mlir
```
the forth, I modify my verify tool(named as "lunar-opt"), and the .cpp file like this:
```
#include "mlir/InitAllDialects.h"
#include "mlir/InitAllPasses.h"
#include "mlir/Pass/PassManager.h"
#include "mlir/Pass/PassRegistry.h"
#include "mlir/Tools/mlir-opt/MlirOptMain.h"
#include "Dialect/Lunar/LunarDialect.h"
int main(int argc, char **argv) {
mlir::DialectRegistry registry;
registry.insert();
mlir::registerAllDialects(registry);
mlir::registerAllPasses();
return mlir::asMainReturnCode(
mlir::MlirOptMain(argc, argv, "lunar_opt Pass Driver", registry));
}
```
the fifth, I create a verify .mlir file, like this:
```
module {
func.func @main(%arg0: !lunar.array) -> !lunar.array {
return %arg0 : !lunar.array
}
}
```
at last, I execute the "lunar-opt", and it throws the errors as following:
```
lunar_test_0.mlir:2:39: error: expected non-function type
func.func @main(%arg0: !lunar.array) -> !lunar.array {
^
lunar_test_0.mlir:2:39: error: failed to parse ArrayData parameter 'dataType' which is to be a `Type`
func.func @main(%arg0: !lunar.array) -> !lunar.array {
```
I guess the "i32" is not in the enums of mlir.Type according to above errors,
I don't know why the mlir cannot accept the "i32"
So, is there anyone would like to teach me how to fix this trouble?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125174] how to define an array in mlir?
Issue
125174
Summary
how to define an array in mlir?
Labels
mlir
Assignees
Reporter
Shaquille-Wu
hello, llvm&mlir experts
I have a trouble about defining a array in mlir.
first, I define a Dialect named as lunar, it is very simple dialect like this in .td file:
```
#ifndef LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
#define LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
include "mlir/IR/OpBase.td"
def Lunar_Dialect : Dialect {
let name = "lunar";
let summary = "A dialect for elementwise math";
let description = [{
The lunar dialect defines types and operations for elementwise computation.
}];
let cppNamespace = "::mlir::lunar";
let useDefaultTypePrinterParser = 1;
}
#endif // LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
```
second, I define a datatype named as "array" in another .td file, like this:
```
#ifndef LIB_DIALECT_LUNAR_LUNARTYPES_TD_
#define LIB_DIALECT_LUNAR_LUNARTYPES_TD_
include "LunarDialect.td"
include "mlir/IR/AttrTypeBase.td"
include "mlir/IR/BuiltinTypes.td"
include "mlir/IR/BuiltinTypeInterfaces.td"
// A base class for all types in this dialect
class Lunar_Type traits = []> : TypeDef {
let mnemonic = typeMnemonic;
}
def ArrayData : Lunar_Type<"ArrayData", "array"> {
let summary = "A array data";
let description = [{
A type for array.
}];
let parameters = (ins "Type":$dataType, "int":$size);
let assemblyFormat = [{ `<` $dataType `x` $size `>` }];
}
#endif // LIB_DIALECT_LUNAR_LUNARTYPES_TD_
```
the third, I modify my the .cpp file about LunarDialect like this:
```
#include "LunarDialect.h"
#include "LunarTypes.h"
#include "mlir/IR/Builders.h"
#include "mlir/IR/BuiltinTypes.h"
#include "mlir/IR/DialectImplementation.h"
#include "llvm/ADT/TypeSwitch.h"
#include "Dialect/Lunar/LunarDialect.cpp.inc"
#define GET_TYPEDEF_CLASSES
#include "Dialect/Lunar/LunarTypes.cpp.inc"
namespace mlir {
namespace lunar {
void LunarDialect::initialize() {
addTypes<
#define GET_TYPEDEF_LIST
#include "Dialect/Lunar/LunarTypes.cpp.inc"
>();
}
} // namespace poly
} // namespace mlir
```
the forth, I modify my verify tool(named as "lunar-opt"), and the .cpp file like this:
```
#include "mlir/InitAllDialects.h"
#include "mlir/InitAllPasses.h"
#include "mlir/Pass/PassManager.h"
#include "mlir/Pass/PassRegistry.h"
#include "mlir/Tools/mlir-opt/MlirOptMain.h"
#include "Dialect/Lunar/LunarDialect.h"
int main(int argc, char **argv) {
mlir::DialectRegistry registry;
registry.insert();
mlir::registerAllDialects(registry);
mlir::registerAllPasses();
return mlir::asMainReturnCode(
mlir::MlirOptMain(argc, argv, "lunar_opt Pass Driver", registry));
}
```
at last, I execute the "lunar-opt", and it throws the errors as following:
```
lunar_test_0.mlir:2:39: error: expected non-function type
func.func @main(%arg0: !lunar.array) -> !lunar.array {
^
lunar_test_0.mlir:2:39: error: failed to parse ArrayData parameter 'dataType' which is to be a `Type`
func.func @main(%arg0: !lunar.array) -> !lunar.array {
```
I guess the "i32" is not in the enums of mlir.Type according to above errors,
I don't know why the mlir cannot accept the "i32"
So, is there anyone would like to teach me how to fix this trouble?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125175] how to define a array in mlir?
Issue
125175
Summary
how to define a array in mlir?
Labels
mlir
Assignees
Reporter
Shaquille-Wu
hello, llvm&mlir experts
I have a trouble about defining a array in mlir.
first, I define a Dialect named as lunar, it is very simple dialect like this in .td file:
```
#ifndef LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
#define LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
include "mlir/IR/OpBase.td"
def Lunar_Dialect : Dialect {
let name = "lunar";
let summary = "A dialect for elementwise math";
let description = [{
The lunar dialect defines types and operations for elementwise computation.
}];
let cppNamespace = "::mlir::lunar";
let useDefaultTypePrinterParser = 1;
}
#endif // LIB_DIALECT_LUNAR_LUNARDIALECT_TD_
```
second, I define a datatype named as "array" in another .td file, like this:
```
#ifndef LIB_DIALECT_LUNAR_LUNARTYPES_TD_
#define LIB_DIALECT_LUNAR_LUNARTYPES_TD_
include "LunarDialect.td"
include "mlir/IR/AttrTypeBase.td"
include "mlir/IR/BuiltinTypes.td"
include "mlir/IR/BuiltinTypeInterfaces.td"
// A base class for all types in this dialect
class Lunar_Type traits = []> : TypeDef {
let mnemonic = typeMnemonic;
}
def ArrayData : Lunar_Type<"ArrayData", "array"> {
let summary = "A array data";
let description = [{
A type for array.
}];
let parameters = (ins "Type":$dataType, "int":$size);
let assemblyFormat = [{ `<` $dataType `x` $size `>` }];
}
#endif // LIB_DIALECT_LUNAR_LUNARTYPES_TD_
```
the third, I modify my the .cpp file about LunarDialect like this:
```
#include "LunarDialect.h"
#include "LunarTypes.h"
#include "mlir/IR/Builders.h"
#include "mlir/IR/BuiltinTypes.h"
#include "mlir/IR/DialectImplementation.h"
#include "llvm/ADT/TypeSwitch.h"
#include "Dialect/Lunar/LunarDialect.cpp.inc"
#define GET_TYPEDEF_CLASSES
#include "Dialect/Lunar/LunarTypes.cpp.inc"
namespace mlir {
namespace lunar {
void LunarDialect::initialize() {
addTypes<
#define GET_TYPEDEF_LIST
#include "Dialect/Lunar/LunarTypes.cpp.inc"
>();
}
} // namespace poly
} // namespace mlir
```
the forth, I modify my verify tool(named as "lunar-opt"), and the .cpp file like this:
```
#include "mlir/InitAllDialects.h"
#include "mlir/InitAllPasses.h"
#include "mlir/Pass/PassManager.h"
#include "mlir/Pass/PassRegistry.h"
#include "mlir/Tools/mlir-opt/MlirOptMain.h"
#include "Dialect/Lunar/LunarDialect.h"
int main(int argc, char **argv) {
mlir::DialectRegistry registry;
registry.insert();
mlir::registerAllDialects(registry);
mlir::registerAllPasses();
return mlir::asMainReturnCode(
mlir::MlirOptMain(argc, argv, "lunar_opt Pass Driver", registry));
}
```
at last, I execute the "lunar-opt", and it throws the errors as following:
```
lunar_test_0.mlir:2:39: error: expected non-function type
func.func @main(%arg0: !lunar.array) -> !lunar.array {
^
lunar_test_0.mlir:2:39: error: failed to parse ArrayData parameter 'dataType' which is to be a `Type`
func.func @main(%arg0: !lunar.array) -> !lunar.array {
```
I guess the "i32" is not in the enums of mlir.Type according to above errors,
I don't know why the mlir cannot accept the "i32"
So, is there anyone would like to teach me how to fix this trouble?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125068] [flang] Exporting symbols for Windows DLLs
Issue 125068 Summary [flang] Exporting symbols for Windows DLLs Labels flang Assignees Reporter godotalgorithm Does LLVM flang have any features that export symbols for Windows DLLs? `dllimport` support was eventually [added to classic flang](https://github.com/flang-compiler/flang/issues/320), but that doesn't seem to work in the latest release of LLVM flang. Are there any tools available to build a symbol definition file (`.def`) that is sometimes used in place of `dllimport` commands? Are there any features right now that facilitate the special case of Fortran symbols with C bindings? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125079] [TySan] False positives accessing base class member variables
Issue
125079
Summary
[TySan] False positives accessing base class member variables
Labels
new issue
Assignees
gbMattN
Reporter
gbMattN
```
class Base{
public:
void* first;
void* second;
};
class Derrived : public Base{};
Derrived derr;
int main(){
derr.second = nullptr;
return 0;
}
```
Results in the following false positive
```
==191047==ERROR: TypeSanitizer: type-aliasing-violation on address 0x64fe5b465d00 (pc 0x64fe5ab0df8f bp 0x7ffc691b0050 sp 0x7ffc691af7f8 tid 191047)
WRITE of size 8 at 0x64fe5b465d00 with type p1 void (in Base at offset 8) accesses part of an existing object of type Derrived that starts at offset -8
#0 0x64fe5ab0df8e in main inherited_member.cpp:12:17
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125078] [clang] `alloc_align` attribute crashes if applied to a function pointer
Issue 125078 Summary [clang] `alloc_align` attribute crashes if applied to a function pointer Labels clang:frontend Assignees Reporter MacDue Reproducer: ``` void aa_fn_ptr(int* (*member)(int) __attribute__((alloc_align(1; ``` Compile with clang (any options) CE: https://godbolt.org/z/14zxWYdM4 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125071] Missing some symbol definitions in module build
Issue 125071 Summary Missing some symbol definitions in module build Labels clang:modules Assignees Reporter hokein Originally reported in https://issues.chromium.org/issues/390537876. The minimal testcase is at https://github.com/hokein/module-bugs/tree/main/undefine ``` $ CLANG=/llvm-project/build-debug/bin/clang ./run.sh $ ... util.cc:(.text._Z1fv[_Z1fv]+0x5): undefined reference to `void x()' clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125088] [flang][OpenMP] The compilation fails with nowait on target construct with -g.
Issue 125088 Summary [flang][OpenMP] The compilation fails with nowait on target construct with -g. Labels flang Assignees abidh Reporter abidh Please see the testcase below. ``` program nowait_reproducer implicit none real x !$omp target map(tofrom: x) nowait x = x + 1 !$omp end target end program nowait_reproducer ``` This is what I get when I try to compile it with -g. ``` flang -g -O0 test.f90 -fopenmp flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option] inlinable function call in a function with debug info must have a !dbg location call void @__omp_offloading_10302_4986ae0__QQmain_l10(ptr %1) error: failed to create the LLVM module ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125092] [libc][test] make DeathTestExecutors and FPExceptionHelpers hermetic
Issue 125092 Summary [libc][test] make DeathTestExecutors and FPExceptionHelpers hermetic Labels libc Assignees nickdesaulniers Reporter nickdesaulniers Towards the goal of being able to cross compile full builds, I hit a snag yesterday when cross compiling some of the unit tests. With some other smaller fixes to our cmake, I can cross compile (and run in QEMU) _some_ unit tests, but quite a few still fail to build. 80cf21dad150a added a [TODO](https://github.com/llvm/llvm-project/blob/c39fba209ce655cf5997878b0bf794da269f008a/libc/test/UnitTest/CMakeLists.txt#L29-L30) that implies that the LibcDeathTestExecutors and LibcFPExceptionHelpers are indeed not yet hermetic. (It then unsets `LLVM_LIBC_FULL_BUILD` which changes the set compiler options from `_get_common_test_compile_options`). Here's an example failure: ``` llvm-project/libc/test/UnitTest/LibcDeathTestExecutors.cpp:15:10: fatal error: 'assert.h' file not found 15 | #include | ^~ ``` I suspect we can start relying on hdr/ for these from the UnitTests. So that needs to get fixed first, before we can cross compile the entire unit test suite. cc @lntue --- FWIW, my cmake invocation is: ``` $ cmake ../runtimes -GNinja -DLLVM_ENABLE_LLD=ON -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_RUNTIMES="libc" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_LIBC_FULL_BUILD=ON -DLIBC_TARGET_TRIPLE=aarch64-linux-gnu -DCMAKE_CROSSCOMPILING_EMULATOR=qemu-aarch64 -DLIBC_KERNEL_HEADERS=/tmp/sysroot/include ``` and my kernel headers were built via: ``` $ make LLVM=1 ARCH=arm64 INSTALL_HDR_PATH=/tmp/sysroot headers_install ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125054] LLDB Windows: Hardware Watchpoints Not Triggering on Initial Stop
Issue 125054 Summary LLDB Windows: Hardware Watchpoints Not Triggering on Initial Stop Labels new issue Assignees Reporter omjavaid Hardware breakpoints and watchpoints set at the initial stop (process launch -s) do not trigger, even though they are correctly written to the Windows context. They only work if set after the program reaches main. This issue affects both AArch64 and x86_64 hardware watchpoints. This issue was discovered while implementing hardware breakpoint and watchpoint support for AArch64 Windows #108072 . Due to the impact, hardware breakpoints were dropped, but watchpoints were retained. The same applies to x86_64 Windows, which only implements hardware breakpoints **Reproduction Steps:** 1. Launch a process using `process launch -s` (stops at the first instruction). 2. Set a hardware watchpoint. 3. Resume execution (continue). 4. The program runs to completion without the hardware watchpoint triggering. 5. Repeat using process launch -m (stops at main). 6. Set the same hardware watchpoint and resume. 7. The watchpoint now triggers correctly. **Underlying Problem:** Windows loader operations between the first instruction and main may disables hardware breakpoints and watchpoints and only enables at the start of main function. LLDB requires a running process to set watchpoints, making this issue less frequent for watchpoints but critical for breakpoints. Does not affect LLDB tests, as hardware breakpoints are not supported on windows due to this problem, and watchpoints are always set after a software breakpoint on main. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125060] Request Commit Access For rscottmanley
Issue 125060 Summary Request Commit Access For rscottmanley Labels infra:commit-access-request Assignees Reporter rscottmanley Working on Flang/MLIR for NVIDIA ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125101] Request Commit Access For ajordanr-google
Issue 125101 Summary Request Commit Access For ajordanr-google Labels infra:commit-access-request Assignees Reporter ajordanr-google ### Why Are you requesting commit access ? Hello! I am from the ChromeOS LLVM Toolchain team at Google. I've been working on our [downstream LLVM](https://chromium-review.googlesource.com/q/owner:ajord...@google.com) for about 4 years now. Despite this fact, I've never actually bothered to get commit access. Requesting commit access now, as I would like to do some work in compiler-rt/lib/scudo with Christopher Ferris. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125102] [libc][POSIX] provide waitpid from sys/wait.h
Issue 125102 Summary [libc][POSIX] provide waitpid from sys/wait.h Labels libc Assignees Reporter nickdesaulniers In order to make out unit tests hermetic for cross compilation, we need to implement `waitpid` from sys/wait.h for use in libc/test/UnitTest/ExecuteFunctionUnix.cpp. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125105] [win/asan] Failing to get instruction size of ucrtbase.dll strstr
Issue 125105 Summary [win/asan] Failing to get instruction size of ucrtbase.dll strstr Labels new issue Assignees Reporter agudbrand Asan reports: ``` ==44184==interception_win: unhandled instruction at 0x78c23a40: 44 0f b6 1a 4c 8b d2 48 ``` Happening on a locally built llvm, compiling with clang++. When I initially built LLVM it wasn't working, but I rebuilt it and it started working, but I needed to rebuild it again and now it no longer works. I am building from [this commit](https://github.com/llvm/llvm-project/commit/dd3edc8365112c47ea01cc942c8223749d007608) and the CMake command used to configure the build files was: ``` cmake ../../src/llvm -G "Visual Studio 17 2022" -DLLVM_OPTIMIZED_TABLEGEN=ON "-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DLLVM_INCLUDE_TESTS=OFF ``` LLVM was compiled using MSVC 2022 17.12.4. Asan is compiled into the program using `-fsanitize=address`. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125126] [HLSL] Generate unique key object for resource handles
Issue 125126 Summary [HLSL] Generate unique key object for resource handles Labels new issue Assignees V-FEXrt Reporter V-FEXrt Late stage analysis such as #114130 require the ability to decern if handles are referencing the same resource. Infrastructure should be added to generate a value/key that is unique per resource given a `llvm::Value` to the ident. Tex's notes: - optionally drill through an AnnotateHandle (depending on shader target) - value should be a CreateHandle of one kind or another. There are four types, depending on target and whether it's a dynamic resource. - `CreateHandle` - bound resource on non-lib SM 6.5 and below: use `resourceClass`, `rangeId` (index into metadata for the resource range), and the `index` to uniquely identify as a bound resource. - `CreateHandleFromBinding` - bound resource on non-lib SM 6.6 and above: Use `resbind` and `index` to uniquely identify as a bound resource. - `CreateHandleFromHeap` - dynamic resource or sampler from heap (SM 6.6+): Use `samplerHeap` to determine whether sampler or other resource Use `index` value to uniquely identify resource. - `CreateHandleForLib` - create handle for library targets Use input `obj` loaded from global variable to uniquely identify resource (GV may be indexed with GEP) In each case, `index` may be dynamic, in which case, if it's not the same `Value*`, you can't tell if it's the same resource as another value. For `CreateHandleForLib` the potential GEP from GV may have the dynamic index, so the combination of the GV and GEP indices are the key. There is also the `nonUniformIndex` flag which might require some special consideration. AC: - Unit tests verify that same resource handles map to an identical key while different handles don't. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125113] llvm-objcopy prints wrong path when output directory doesn't exist
Issue 125113 Summary llvm-objcopy prints wrong path when output directory doesn't exist Labels new issue Assignees Reporter srpape When the output directory doesn't exist, llvm-objcopy prints the input argument in the error string. Tested with llvm-objcopy-19. Example to reproduce: ```sh # We get permission denied if we try to use /usr/bin/ls directly $ cp /usr/bin/ls ./ls # ./invalid-dir does not exist, we get an incorrect error message $ llvm-objcopy-19 --dump-section .text=./invalid-dir/text ./ls llvm-objcopy-19: error: './ls': No such file or directory # If we create the directory, it will succeed $ mkdir invalid-dir $ llvm-objcopy-19 --dump-section .text=./invalid-dir/text ./ls #succeeds ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125124] sparcv9 unsupported argument '-Av9b' to option '-Wa, '
Issue 125124 Summary sparcv9 unsupported argument '-Av9b' to option '-Wa,' Labels new issue Assignees Reporter bsdkurt oracle$ echo | clang -Wa,-Av9b -x c - clang: error: unsupported argument '-Av9b' to option '-Wa,' oracle$ clang -v OpenBSD clang version 19.1.7 Target: sparc64-unknown-openbsd7.6 Thread model: posix InstalledDir: /usr/bin -Wa,-Av9b is supported by gcc on sparc and it would be helpful if clang would support it as well so makefiles don't have to conditionally use -Wa,-mcpu=niagara for clang and -Wa,-Av9b for gcc. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125121] SPIRVAPITests fail on GitHub macOS ARM runners
Issue
125121
Summary
SPIRVAPITests fail on GitHub macOS ARM runners
Labels
new issue
Assignees
Reporter
tstellar
The SPIRVAPITest tests are failing when run on the macOS ARM runners. Full log can be found here: https://github.com/tstellar/llvm-project/actions/runs/12967738035/job/36169942578
```
FAIL: LLVM-Unit :: Target/SPIRV/./SPIRVTests/0/4 (55452 of 55525)
TEST 'LLVM-Unit :: Target/SPIRV/./SPIRVTests/0/4' FAILED
Script(shard):
--
GTEST_OUTPUT=json:/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests-LLVM-Unit-45168-0-4.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=4 GTEST_SHARD_INDEX=0 /Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests
--
Script:
--
/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests --gtest_filter=SPIRVAPITest.checkTranslateUnknownExtensionByOpts
--
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:168: Failure
Death test: { toSpirv(ExtensionAssembly, Result, Error, {}, Opts); }
Result: failed to die.
Error msg:
[ DEATH ] SPIRVTranslateModule: for the --spirv-ext option: Unknown SPIR-V extension: +SPV_XYZ_my_unknown_extension
[ DEATH ]
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:168
Death test: { toSpirv(ExtensionAssembly, Result, Error, {}, Opts); }
Result: failed to die.
Error msg:
[ DEATH ] SPIRVTranslateModule: for the --spirv-ext option: Unknown SPIR-V extension: +SPV_XYZ_my_unknown_extension
[ DEATH ]
Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
FAIL: LLVM-Unit :: Target/SPIRV/./SPIRVTests/1/4 (55453 of 55525)
TEST 'LLVM-Unit :: Target/SPIRV/./SPIRVTests/1/4' FAILED
Script(shard):
--
GTEST_OUTPUT=json:/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests-LLVM-Unit-45168-1-4.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=4 GTEST_SHARD_INDEX=1 /Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests
--
Script:
--
/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests --gtest_filter=SPIRVAPITest.checkTranslateAllExtensions
--
Invalid optimization level!/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:140: Failure
Value of: Status && Error.empty() && !Result.empty()
Actual: false
Expected: true
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:141: Failure
Expected equality of these values:
identify_magic(Result)
Which is: 0
file_magic::spirv_object
Which is: 39
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:140
Value of: Status && Error.empty() && !Result.empty()
Actual: false
Expected: true
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:141
Expected equality of these values:
identify_magic(Result)
Which is: 0
file_magic::spirv_object
Which is: 39
Script:
--
/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests --gtest_filter=SPIRVAPITest.checkTranslateWrongExtensionByOpts
--
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:177: Failure
Death test: { toSpirv(ExtensionAssembly, Result, Error, {}, Opts); }
Result: failed to die.
Error msg:
[ DEATH ] Invalid optimization level!
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:177
Death test: { toSpirv(ExtensionAssembly, Result, Error, {}, Opts); }
Result: failed to die.
Error msg:
[ DEATH ] Invalid optimization level!
Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
FAIL: LLVM-Unit :: Target/SPIRV/./SPIRVTests/2/4 (55454 of 55525)
TEST 'LLVM-Unit :: Target/SPIRV/./SPIRVTests/2/4' FAILED
Script(shard):
--
GTEST_OUTPUT=json:/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests-LLVM-Unit-45168-2-4.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=4 GTEST_SHARD_INDEX=2 /Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests
--
Script:
--
/Users/runner/work/llvm-project/llvm-project/build/unittests/Target/SPIRV/./SPIRVTests --gtest_filter=SPIRVAPITest.checkTranslateWrongExtensionByArg
--
/Users/runner/work/llvm-project/llvm-project/llvm/unittests/Target/SPIRV/SPIRVAPITest.cpp:186: Failure
Death test: { toSpirv(ExtensionAssembly, Result, Error, ExtNames, {}); }
Result: failed to die.
Error msg:
[ DEATH ]
/Users/runner/work/llvm-project/llvm-proje
[llvm-bugs] [Bug 125163] the following openacc code for matrix multiplication works in nvc++ on the nvidia device and fails on the target on clang. It does not update the host after acc_update_self. c
Issue 125163 Summary the following openacc code for matrix multiplication works in nvc++ on the nvidia device and fails on the target on clang. It does not update the host after acc_update_self. clang also puts wrong parameters into a function on the host Labels clang Assignees Reporter bschulz81 Compared to last time, i replaced the mapping macros with acc_copyin, acc_create, acc_attach, acc_update_self and acc_detach and acc_exit functions. One can now clearly see that they do not work clang 20.0.0_pre20250122 the data for the matrix multiplication is not downloaded and probably also not uploaded or attached, one sees the zero results in the output and the function for the lu decomposition can not access the device buffer if uploaded on the device. however, what is more, the lu decomposition seems to work if we want to multiply on device only. But in fact, it calculation is done on the host because the parameter algorithm.gpu_offload that is the function supplied to matrix_multiply_dot is set to false by clang despite me having set it to true! As far as i can see, my code is now fully within the openmp and openacc standards. This is certainly a strange output. i never saw a compiler apparently changing function parameters... a debug shows that on nvc++ they are supplied correctly... [mdspan_acc.h.txt](https://github.com/user-attachments/files/18612948/mdspan_acc.h.txt) [main_acc.cpp.txt](https://github.com/user-attachments/files/18612950/main_acc.cpp.txt) [CMakeLists.txt](https://github.com/user-attachments/files/18612951/CMakeLists.txt) [clangoutput.txt](https://github.com/user-attachments/files/18612961/clangoutput.txt) [nvc++output.txt](https://github.com/user-attachments/files/18612971/nvc%2B%2Boutput.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125039] [AVR] Force relocations for non-encodable jumps (backport)
Issue 125039 Summary [AVR] Force relocations for non-encodable jumps (backport) Labels new issue Assignees Reporter Patryk27 /cherry-pick b7dc69132519d6eef747b9d121d2db7046b3dfb8 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 125047] Crash while processing readability-simplify-boolean-expr
Issue 125047 Summary Crash while processing readability-simplify-boolean-expr Labels new issue Assignees Reporter mathijskolkhuistanke clang-tidy crashes while parsing a C++ file. ``` Stack dump: 0. Program arguments: clang-tidy -p D:\\Jenkins\\workspace\\REM_DESKTOP_CLANG\\scripts\\clang\\..\\..\\out\\ClangTidy\\ -header-filter=Components.*\\.h -quiet D:\\Jenkins\\workspace\\REM_DESKTOP_CLANG\\Components\\CalculationWals\\VastgoedCalculation\\DetailProjectsCashFlowCalculator.cpp 1. parser at end of file 2. ASTMatcher: Processing 'readability-simplify-boolean-expr' against: TranslationUnitDecl : <> No bound nodes Exception Code: 0xC005 #0 0x7ff76223b5d6 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x44b5d6) #1 0x7ff76223c1c3 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x44c1c3) #2 0x7ff762b5fed7 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0xd6fed7) #3 0x7ff762b5f1da (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0xd6f1da) #4 0x7ff762752832 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x962832) #5 0x7ff7627614a2 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x9714a2) #6 0x7ff762758d46 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x968d46) #7 0x7ff762761424 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x971424) #8 0x7ff762758d46 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x968d46) #9 0x7ff762766f80 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x976f80) #10 0x7ff762754554 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x964554) #11 0x7ff762758095 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x968095) #12 0x7ff762752ec3 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x962ec3) #13 0x7ff7627546eb (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x9646eb) #14 0x7ff7627555bf (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x9655bf) #15 0x7ff762752f77 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x962f77) #16 0x7ff762750128 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x960128) #17 0x7ff762faa463 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x11ba463) #18 0x7ff763074cb4 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x1284cb4) #19 0x7ff762fa99a8 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x11b99a8) #20 0x7ff762fab250 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x11bb250) #21 0x7ff762f9691a (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x11a691a) #22 0x7ff762fd30c3 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x11e30c3) #23 0x7ff7629c0178 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0xbd0178) #24 0x7ff761e057e1 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x157e1) #25 0x7ff761e05342 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x15342) #26 0x7ff762268ef7 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x478ef7) #27 0x7ff7621b55a5 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x3c55a5) #28 0x7ff762268d95 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x478d95) #29 0x7ff762267d50 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x477d50) #30 0x7ff76226a7fd (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x47a7fd) #31 0x7ff7621b078a (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x3c078a) #32 0x7ff762173eb4 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x383eb4) #33 0x7ff762eb7db8 (D:\Tools\Clang 19.1.0\bin\clang-tidy.exe+0x10c7db8) #34 0x7ffb8c227ac4 (C:\WINDOWS\System32\KERNEL32.DLL+0x17ac4) #35 0x7ffb8c62a8c1 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5a8c1) ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
