[llvm-bugs] [Bug 140236] [clang-tidy] "modernize-pass-by-value" - should ignore move constructors from protected/private section
Issue
140236
Summary
[clang-tidy] "modernize-pass-by-value" - should ignore move constructors from protected/private section
Labels
clang-tidy
Assignees
Reporter
denzor200
```
class A {
std::string m_val;
public:
A() = default;
A(const A& other) = default;
A& operator= (const A& other) = default;
protected:
A(A&& other) = default;
A& operator= (A&& other) = default;
};
```
This protected move constructor must be ignored, redundant warning with invalid fixit must not be provided. Also we should pay attention for friend classes.
[Full snippet](https://godbolt.org/z/oW317haY4)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140238] [LoopInterchange] Incorrect exchange happens when the Levels of Dependence is less than the depth of the loop nest
Issue
140238
Summary
[LoopInterchange] Incorrect exchange happens when the Levels of Dependence is less than the depth of the loop nest
Labels
new issue
Assignees
Reporter
kasuga-fj
Input:
```c
#include
float A[4][4];
float V[16];
void g(float *dst, float *src) {
for (int j = 0; j < 4; j++)
for (int i = 0; i < 4; i++)
dst[i * 4 + j] = src[j * 4 + i] + A[i][j];
}
int main(void) {
for (int i = 0; i < 16; i++) {
A[i / 4][i % 4] = i;
V[i] = i * i;
}
g(V, V);
for (int i = 0; i < 16; i++)
printf("V[%d]=%f\n", i, V[i]);
return 0;
}
```
godbolt: https://godbolt.org/z/dq6Kad14a
The root cause is that the dependency matrix for the loops in `g` is `I I`, which is treated same as `= =` in legality check. An `I` dependence is used to fill a direction vector if its length is less than the depth of the loop nest.
https://github.com/llvm/llvm-project/blob/9f77c26ec641c7f0c353f74ee6ee072086e2f3d7/llvm/lib/Transforms/Scalar/LoopInterchange.cpp#L212-L214
In this case, since the alias check results in MayAlias, DependenceInfo skips the analysis and returns a default Dependence object, whose `Levels` is always 0.
https://github.com/llvm/llvm-project/blob/b712590ef4acfd9f0bea42aff695b22ca99ae5dd/llvm/lib/Analysis/DependenceAnalysis.cpp#L3605-L3609
A similar problem occurs when the dimension of arrays used in the target loops is less than the depth of the loop nest, such as in the following case
```c
float A[4][4][4];
float V[4];
void f() {
for (int i = 0; i < 4; i++)
for (int j = 0; j < 4; j++)
for (int k = 0; k < 4; k++)
V[i] += A[i][j][k];
}
```
godbolt: https://godbolt.org/z/Yss6oe3eb
In this case, exchanging the j- and k-loop fails because the IR structure is currently unsupported. However, it should be rejected by dependence reason, because that exchange changes the order of addition of float values.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140280] Add a pass that materializes the alias analysis into metadata
Issue 140280 Summary Add a pass that materializes the alias analysis into metadata Labels new issue Assignees Reporter krzysz00 There are various transformations - one main one is the assumption stripping in `codegenprepare`, but there's also target-specific stuff like the AMDGPU kernel argument lowering - that lose alias information. This alias information could be preserved in `!noalias` and `!alias.scope` metadata (somewhat like the inliner does), but, currently, no effort is made to do so. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140321] [DirectX] DXILBitcodeWriter is trying to encode unsupported TargetExtTyID
Issue
140321
Summary
[DirectX] DXILBitcodeWriter is trying to encode unsupported TargetExtTyID
Labels
new issue
Assignees
Reporter
farzonl
## repro
```bash
lldb -- clang-dxc DirectML/Product/Shaders/Generated/Cast_float16_native_accum32_uint64_emulated_256_Strided4D.hlsl -E CSMain -T cs_6_2 -enable-16bit-types -O3 -D DXC_COMPILER=1 -D __SHADER_TARGET_MAJOR=6 -D __SHADER_TARGET_MINOR=2 -I DirectML/Product/Shaders/ -Fo /validation/Cast_float16_native_accum32_uint64_emulated_256_Strided4D.dat
```
## fatal error location
https://github.com/llvm/llvm-project/blob/286ab11dc65de8175e2bce69fd7e36acd3be7ce0/llvm/lib/Target/DirectX/DXILWriter/DXILBitcodeWriter.cpp#L1024-L1026
```gdb
(lldb) expr T->dump()
target("dx.RawBuffer", %struct.uint64_emulated, 1, 0)
(lldb) expr *T
(llvm::Type) $1 = {
Context = 0x00011f00b010
ID = TargetExtTyID
SubclassData = 2
NumContainedTys = 1
ContainedTys = 0x00011f977570
```
## crash stack
```bash
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x000102027e68 clang-dxc`llvm::dxil::DXILBitcodeWriter::writeTypeTable(this=0x00016fdf5708) at DXILBitcodeWriter.cpp:1025:7 [opt]
frame #1: 0x000102025580 clang-dxc`llvm::dxil::DXILBitcodeWriter::write(this=0x00016fdf5708) at DXILBitcodeWriter.cpp:2888:3 [opt]
frame #2: 0x0001020252c0 clang-dxc`llvm::dxil::BitcodeWriter::writeModule(this=0x00016fdf5a40, M=0x00011f006c50) at DXILBitcodeWriter.cpp:436:16 [opt]
frame #3: 0x000102025098 clang-dxc`llvm::dxil::WriteDXILToFile(M=0x00011f006c50, Out=0x00016fdf5be0) at DXILBitcodeWriter.cpp:406:10 [opt]
frame #4: 0x000102041724 clang-dxc`(anonymous namespace)::EmbedDXILPass::runOnModule(this=, M=0x00011f006c50) at DXILWriterPass.cpp:73:5 [opt]
frame #5: 0x000100c103fc clang-dxc`llvm::legacy::PassManagerImpl::run(llvm::Module&) at LegacyPassManager.cpp:1521:27 [opt]
frame #6: 0x000100c101c4 clang-dxc`llvm::legacy::PassManagerImpl::run(this=, M=0x00011f006c50) at LegacyPassManager.cpp:539:44 [opt]
frame #7: 0x0001017f8fb0 clang-dxc`clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::__1::unique_ptr>, clang::BackendConsumer*) at BackendUtil.cpp:1262:19 [opt]
frame #8: 0x0001017f8d18 clang-dxc`clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::__1::unique_ptr>, clang::BackendConsumer*) [inlined] (anonymous namespace)::EmitAssemblyHelper::emitAssembly(this=0x00016fdf5f50, Action="" OS=llvm::raw_pwrite_stream @ 0x00011f008bf0, BC=) at BackendUtil.cpp:1286:3 [opt]
frame #9: 0x0001017f89d4 clang-dxc`clang::emitBackendOutput(CI=0x00011f00a6a0, CGOpts=, TDesc=(Data = "" Length = 78), M=, Action="" VFS=, OS=, BC=0x00011f006a20) at BackendUtil.cpp:1451:13 [opt]
frame #10: 0x000101a5a6ac clang-dxc`clang::BackendConsumer::HandleTranslationUnit(this=0x00011f006a20, C=0x00011e839200) at CodeGenAction.cpp:316:3 [opt]
frame #11: 0x000102925f94 clang-dxc`clang::ParseAST(S=0x00011f82a600, PrintStats=, SkipFunctionBodies=) at ParseAST.cpp:184:13 [opt]
frame #12: 0x000101e800fc clang-dxc`clang::FrontendAction::Execute(this=) at FrontendAction.cpp:1221:3 [opt]
frame #13: 0x000101e1c7e8 clang-dxc`clang::CompilerInstance::ExecuteAction(this=0x00011f00a6a0, Act=0x00011f00c5c0) at CompilerInstance.cpp:1057:33 [opt]
frame #14: 0x000101ef8b64 clang-dxc`clang::ExecuteCompilerInvocation(Clang=0x00011f00a6a0) at ExecuteCompilerInvocation.cpp:300:25 [opt]
frame #15: 0x00019c50 clang-dxc`cc1_main(Argv=, Argv0=, MainAddr=0x000154d4) at cc1_main.cpp:297:15 [opt]
frame #16: 0x00017424 clang-dxc`ExecuteCC1Tool(ArgV=, ToolContext=0x00016fdfe8c8) at driver.cpp:223:12 [opt]
frame #17: 0x000101ca719c clang-dxc`void llvm::function_ref::callback_fn>, std::__1::basic_string, std::__1::allocator>*, bool*) const::$_0>(long) [inlined] llvm::function_ref&)>::operator()(this=, params=) const at STLFunctionalExtras.h:69:12 [opt]
frame #18: 0x000101ca7190 clang-dxc`void llvm::function_ref::callback_fn>, std::__1::basic_string, std::__1::allocator>*, bool*) const::$_0>(long) [inlined] clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__1::basic_string, std::__1::allocator>*, bool*) const::$_0::operator()(this=0x00016fdfa0d0) const at Job.cpp:436:34 [opt]
frame #19: 0x000101ca718c clang-dxc`void llvm::function_ref::callback_fn>, std::__1::basic_string, std::__1::allocator>*, bool*) const::$_0>(callable=6171893968) at
[llvm-bugs] [Bug 140318] Check if the client reports the supportsConfigurationDoneRequest capability
Issue 140318 Summary Check if the client reports the supportsConfigurationDoneRequest capability Labels lldb-dap Assignees Reporter JDevlieghere Our current implementation unconditionally assumes we'll get a `configurationDone`, but not all clients support the `configurationDone`. We need to check the capabilities reported by our client and only rely on it when the client supports the request. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140297] Request Commit Access For Andres-Salamanca
Issue 140297 Summary Request Commit Access For Andres-Salamanca Labels infra:commit-access-request Assignees Reporter Andres-Salamanca ### Why Are you requesting commit access ? I would like to request commit access to the LLVM repo. This would allow me to assign reviewers and push changes after reviews have been approved. I’ve recently started contributing to the ClangIR upstreaming effort, and I believe I already have four PRs merged. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140302] Roundtrip `tensor` of `complex`s
Issue
140302
Summary
Roundtrip `tensor` of `complex`s
Labels
new issue
Assignees
Reporter
erick-xanadu
https://godbolt.org/z/5GYYfPs6G
I believe that only the real component of complex is getting parsed.
Input:
```
%complex_tensor_i1 = "test.op"() {"value" = dense<[(true, true), (false, true)]> : tensor<2xcomplex>} : () -> tensor<2xcomplex>
```
Expected output:
```
"builtin.module"() ({
%0 = "test.op"() {value = dense<[(true,true), (false,true)]> : tensor<2xcomplex>} : () -> tensor<2xcomplex>
}) : () -> ()
```
Observed output:
```
"builtin.module"() ({
%0 = "test.op"() {value = dense<[(true,false), (false,false)]> : tensor<2xcomplex>} : () -> tensor<2xcomplex>
}) : () -> ()
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140303] Wrong result of "constructible" traits for unbound arrays
Issue 140303 Summary Wrong result of "constructible" traits for unbound arrays Labels new issue Assignees Reporter bolshakov-a These asserts fail in Clang (and GCC as well): ```cpp static_assert(__is_constructible(int[], int, int)); static_assert(__is_nothrow_constructible(int[], int, int)); ``` However, it seems to be wrong because [[meta.unary.prop] p. 9](http://eel.is/c++draft/meta#unary.prop-9) states: > The predicate condition for a template specialization is_constructible shall be satisfied if and only if the following variable definition would be well-formed for some invented variable t: > `T t(declval()...);` and the following compiles: ```cpp #include template< class T > std::add_rvalue_reference_t declval() noexcept; using T = int[]; T t(declval(), declval()); ``` Is it actually a bug, or am I missing something? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140252] __builtin_round() uses dynamic rounding mode on x86 (only)
Issue 140252 Summary __builtin_round() uses dynamic rounding mode on x86 (only) Labels new issue Assignees Reporter enh-google my assumption was that `__builtin_round()` was meant to be like the `round()` libc function, and for arm and riscv, that's how it behaves: Android's libc can use `__builtin_round()` to implement `round()`. for x86/x86-64 though, `__builtin_round()` seems to use the _dynamic_ rounding mode rather than hard-coding "away from zero" as specified by round(). seems like a bug? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140328] [mlir][arith] Erroneous canonicalization pattern for `arith.addi`
Issue
140328
Summary
[mlir][arith] Erroneous canonicalization pattern for `arith.addi`
Labels
mlir:arith
Assignees
Reporter
math-fehr
When running `mlir-opt --canonicalize` (https://godbolt.org/z/6q9ehf7q7), the following program:
```
func.func @foo(%x : i2) -> i2 {
%c-1 = arith.constant -1 : i2
%c-2 = arith.constant -2 : i2
%temp = arith.addi %x, %c-2 overflow : i2
%res = arith.addi %temp, %c-1 overflow : i2
func.return %res : i2
}
```
gets compiled into the following program:
```
func.func @foo(%arg0: i2) -> i2 {
%c1_i2 = arith.constant 1 : i2
%0 = arith.addi %arg0, %c1_i2 overflow : i2
return %0 : i2
}
```
Note that while I use `i2` for the example, there is equivalent issues for any integer sizes (besides 1). Reminder, the allowed values are `-2, -1, 0, 1` for `i2`.
When the input is 1, the first program will return `-2`, while the second program will return `poison`.
I played a bit with the alive-like tool I am working on, and what I'm getting is that [this canonicalization pattern](https://github.com/llvm/llvm-project/blob/f7ef8dcbad9d5ac6cf2a8917d5ce03564fdfd0d8/mlir/lib/Dialect/Arith/IR/ArithCanonicalization.td#L43) is buggy whenever the two input adds have only the `nsw` flag, or if one has the `nsw` flag and the other has the `nsw` and `nuw` flag.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140330] Assertion failure in ThreadSafetyReporter::handleNoMutexHeld "Only works for variables"
Issue
140330
Summary
Assertion failure in ThreadSafetyReporter::handleNoMutexHeld "Only works for variables"
Labels
new issue
Assignees
Reporter
alexfh
https://gcc.godbolt.org/z/W6MTKqsvz
```
$ cat test.c
struct {
int v __attribute__((guarded_var));
} p;
int *g() {
return &p.v;
}
$ ./clang-bad -Wthread-safety-analysis test.c
assertion failed at clang/lib/Sema/AnalysisBasedWarnings.cpp:1948 in virtual void clang::threadSafety::(anonymous namespace)::ThreadSafetyReporter::handleNoMutexHeld(const NamedDecl *, ProtectedOperationKind, AccessKind, SourceLocation): (POK == POK_VarAccess || POK == POK_VarDereference) && "Only works for variables"
@ 0x55c4b4397ec4 __assert_fail
@ 0x55c4af71b522 clang::threadSafety::(anonymous namespace)::ThreadSafetyReporter::handleNoMutexHeld()
@ 0x55c4b00ede2c (anonymous namespace)::ThreadSafetyAnalyzer::checkAccess()
@ 0x55c4b00debaf (anonymous namespace)::ThreadSafetyAnalyzer::runAnalysis()
@ 0x55c4b00daca4 clang::threadSafety::runThreadSafetyAnalysis()
@ 0x55c4af711fa2 clang::sema::AnalysisBasedWarnings::IssueWarnings()
@ 0x55c4af705eda clang::Sema::PopFunctionScopeInfo()
@ 0x55c4af8b63be clang::Sema::ActOnFinishFunctionBody()
@ 0x55c4af4beed4 clang::Parser::ParseFunctionStatementBody()
@ 0x55c4af41109c clang::Parser::ParseFunctionDefinition()
@ 0x55c4af479264 clang::Parser::ParseDeclGroup()
@ 0x55c4af410066 clang::Parser::ParseDeclOrFunctionDefInternal()
@ 0x55c4af40f85d clang::Parser::ParseDeclarationOrFunctionDefinition()
@ 0x55c4af40e6f9 clang::Parser::ParseExternalDeclaration()
@ 0x55c4af40cd74 clang::Parser::ParseTopLevelDecl()
@ 0x55c4af4089be clang::ParseAST()
@ 0x55c4af153a8a clang::FrontendAction::Execute()
@ 0x55c4af0cd98d clang::CompilerInstance::ExecuteAction()
@ 0x55c4ae51a7ab clang::ExecuteCompilerInvocation()
@ 0x55c4ae50e8a0 cc1_main()
@ 0x55c4ae50bc24 ExecuteCC1Tool()
@ 0x55c4ae50b180 clang_main()
@ 0x55c4ae509674 main
@ 0x7fa386b923d4 __libc_start_main
@ 0x55c4ae5095aa _start
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140329] How to implement relocation of return values
Issue 140329 Summary How to implement relocation of return values Labels new issue Assignees Reporter Tt421 In the llvm-project of emscripten. It use `TypeIndex` in the file `/llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyInstrCall.td` implement the parameter of `CALL_INDIRECT` instruction. I looked at the code briefly and found that it is indeed handling `TypeIndex` in Relocation. If I need to implement an instruction, the return value of this instruction is related to the processing type of TypeIndex. This instruction looks like `ref.null ht`, which `ht` is `𝑥:s33`, the return value of this instruction can be `ref x` (`𝑥` ≥ 0). How can I modify the code of the `llvm-project` to achieve the above effect? Can you give me some implementation suggestions? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140334] [SLP][AMD] Assertion `IsVectorized && "Expected to be vectorized"' failed on Zen1
Issue
140334
Summary
[SLP][AMD] Assertion `IsVectorized && "Expected to be vectorized"' failed on Zen1
Labels
regression,
llvm:SLPVectorizer
Assignees
Reporter
mcinally
This was a regression from around Thurs/Fri of last week (5/8-5/9). It appears to only affect Zen1:
```
[scrubbed@scrubbed repro]$ cat test.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@mbc_dbl = common global [16 x i8] zeroinitializer, align 8
@foo_int = common global [16 x i8] zeroinitializer, align 8
@foo_ptr = common local_unnamed_addr global [640 x i8] zeroinitializer, align 8
define void @foo() {
%165 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 64), align 8
%166 = getelementptr i64, ptr @foo_int, i64 %165
%168 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 80), align 8
%169 = getelementptr i64, ptr @foo_int, i64 %168
%171 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 192), align 8
%172 = getelementptr double, ptr @mbc_dbl, i64 %171
%174 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 128), align 8
%175 = getelementptr double, ptr @mbc_dbl, i64 %174
%177 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 144), align 8
%178 = getelementptr double, ptr @mbc_dbl, i64 %177
%180 = load i64, ptr getelementptr inbounds nuw (i8, ptr @foo_ptr, i64 208), align 8
%181 = getelementptr double, ptr @mbc_dbl, i64 %180
ret void
}
[scrubbed@scrubbed repro]$ opt -mcpu=znver1 -passes=slp-vectorizer -S test.ll
opt: /scrubbed/src/llvm-project/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:13633: auto llvm::slpvectorizer::BoUpSLP::getEntryCost(const TreeEntry *, ArrayRef, SmallPtrSetImpl &)::(anonymous class)::operator()(InstructionCost) const: Assertion `IsVectorized && "Expected to be vectorized"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: opt -mcpu=znver1 -passes=slp-vectorizer -S test.ll
1. Running pass "function(slp-vectorizer)" on module "test.ll"
2. Running pass "slp-vectorizer" on function "foo"
#0 0x019e4738 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /scrubbed/llvm/bin/opt+0x19e4738)
#1 0x019e21ae llvm::sys::RunSignalHandlers() /scrubbed/llvm/bin/opt+0x19e21ae)
#2 0x019e4fa6 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
#3 0x148ce39d3d10 __restore_rt (/lib64/libpthread.so.0+0x12d10)
#4 0x148ce29ef52f raise (/lib64/libc.so.6+0x4e52f)
#5 0x148ce29c2e65 abort (/lib64/libc.so.6+0x21e65)
#6 0x148ce29c2d39 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d39)
#7 0x148ce29e7e86 (/lib64/libc.so.6+0x46e86)
#8 0x03692f50 std::pair, llvm::VectorType*, unsigned int, bool>, llvm::DenseMapInfo, llvm::detail::DenseMapPair, llvm::VectorType*, unsigned int, bool>>, false>, bool> llvm::DenseMapBase, llvm::VectorType*, unsigned int, bool>, 4u, llvm::DenseMapInfo, llvm::detail::DenseMapPair, llvm::VectorType*, unsigned int, bool>>>, llvm::slpvectorizer::BoUpSLP::TreeEntry const*, std::tuple, llvm::VectorType*, unsigned int, bool>, llvm::DenseMapInfo, llvm::detail::DenseMapPair, llvm::VectorType*, unsigned int, bool>>>::try_emplace&, llvm::VectorType*&, unsigned int&, bool&>(llvm::slpvectorizer::BoUpSLP::TreeEntry const* const&, llvm::SmallVector&, llvm::VectorType*&, unsigned int&, bool&) SLPVectorizer.cpp:0:0
#9 0x035f017c llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef, llvm::SmallPtrSetImpl&)::$_2::operator()(llvm::function_ref, llvm::function_ref) const SLPVectorizer.cpp:0:0
#10 0x035eb2e7 llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef, llvm::SmallPtrSetImpl&) /scrubbed/llvm/bin/opt+0x35eb2e7)
#11 0x035f68d7 llvm::slpvectorizer::BoUpSLP::getTreeCost(llvm::ArrayRef, llvm::InstructionCost) /scrubbed/llvm/bin/opt+0x35f68d7)
#12 0x0362f317 llvm::SLPVectorizerPass::tryToVectorizeList(llvm::ArrayRef, llvm::slpvectorizer::BoUpSLP&, bool) /scrubbed/llvm/bin/opt+0x362f317)
#13 0x0362a04f llvm::SLPVectorizerPass::vectorizeGEPIndices(llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) /scrubbed/llvm/bin/opt+0x362a04f)
#14 0x0362545c llvm::SLPVectorizerPass::runImpl(llvm::Function&, llvm::ScalarEvolution*, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo*, llvm::AAResults*, llvm::LoopInfo*, llvm::DominatorTree*, llvm::AssumptionCache*, llvm::DemandedBits*, llvm::OptimizationRemarkEmitter*) /scrubbed/llvm/bin/opt+0x362545c)
#15 0x03624948 llvm::SLPVectorizerPass::run(llvm::Fun
[llvm-bugs] [Bug 140336] [OpenMP] Instruction referencing instruction not embedded in a basic block!
Issue
140336
Summary
[OpenMP] Instruction referencing instruction not embedded in a basic block!
Labels
new issue
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/6954MqYjs
```c
void f (int i)
{
switch (i)
{
int j;
#pragma omp allocate(j)
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140338] [OpenMP] Assertion `(isUnevaluated() || getCharByteWidth() == 1) && "This function is used in places that assume strings use char"' failed.
Issue 140338 Summary [OpenMP] Assertion `(isUnevaluated() || getCharByteWidth() == 1) && "This function is used in places that assume strings use char"' failed. Labels new issue Assignees Reporter k-arrows Reproducer: https://godbolt.org/z/6cKcbE459 ```c #pragma omp error message(L"") ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140339] [OpenACC] UNREACHABLE executed at /root/llvm-project/llvm/tools/clang/lib/Sema/SemaOpenACCClause.cpp:1305!
Issue
140339
Summary
[OpenACC] UNREACHABLE executed at /root/llvm-project/llvm/tools/clang/lib/Sema/SemaOpenACCClause.cpp:1305!
Labels
clang
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/d3xM5dYsv
```cpp
void foo() {
#pragma acc serial loop
for (int i = 0; i < 10; i++) {
#pragma acc loop
for (int j = 0; j < 10; j++) {
#pragma acc loop vector(length : 5)
for (int k = 0; k < 10; k++)
;
}
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140345] [clang] Assertion `NewRange.getLower().slt(NewRange.getUpper())' failed.
Issue
140345
Summary
[clang] Assertion `NewRange.getLower().slt(NewRange.getUpper())' failed.
Labels
clang
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/zYorscvnP
```c
typedef __SIZE_TYPE__ size_t;
void *memset(void *, int, size_t);
void foo(char *p) {
size_t idx = __PTRDIFF_MAX__ - 3;
++idx;
memset(p + idx, 0, 3);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140346] [clang] Assertion `EnumDeclBits.NumPositiveBits == Num && "can't store this bitcount"' failed.
Issue
140346
Summary
[clang] Assertion `EnumDeclBits.NumPositiveBits == Num && "can't store this bitcount"' failed.
Labels
clang
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/oYsceKfW7
```c
enum A { A0 = 9wb};
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140243] [OpenMP] crash on invalid C++ code
Issue
140243
Summary
[OpenMP] crash on invalid C++ code
Labels
new issue
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/4vscKvhW9
```cpp
template
class I { };
struct R { R () {}; ~R () {}; I r; };
struct T { T () {}; virtual ~T () {}; I t; };
struct A : public R, virtual public T { A () {} I a; void m1 (const I &, const I &); };
void A::m1 (const I &x)
{
int w = 0;
#pragma omp parallel for reduction(|:w)
for (a = x; A::a < 10; a++)
w |= (1 << *A::a);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140226] Clang incorrectly assumes function alignment on arm64e
Issue
140226
Summary
Clang incorrectly assumes function alignment on arm64e
Labels
clang
Assignees
Reporter
LIJI32
When targeting arm64e (but not arm64) with -O1 or higher, `clang` assumes functions are aligned to 8 bytes rather than 4 bytes, generating wrong code that might not work.
Minimal reproducing code:
```
extern void external_func(void);
unsigned long get_func(void)
{
return ((unsigned long)(external_func) & 0xFFF);
}
```
Output from `Apple clang version 17.0.0 (clang-1700.0.13.3)`:
`clang -O0 -arch arm64e`
```
_get_func: ; @get_func
adrp x16, _external_func@GOTPAGE
ldr x16, [x16, _external_func@GOTPAGEOFF]
paciza x16
and x0, x16, #0xfff ; Correct
ret
```
`clang -O1 -arch arm64e`
```
_get_func: ; @get_func
adrp x16, _external_func@GOTPAGE
ldr x16, [x16, _external_func@GOTPAGEOFF]
paciza x16
and x0, x16, #0xff8 ; Incorrect
ret
```
`clang -O1 -arch arm64`
```
_get_func: ; @get_func
adrp x8, _external_func@GOTPAGE
ldr x8, [x8, _external_func@GOTPAGEOFF]
and x0, x8, #0xffc ; Correct, but why bother changing the immediate here?
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140239] Incorrect optimization around __builtin_set_flt_rounds
Issue
140239
Summary
Incorrect optimization around __builtin_set_flt_rounds
Labels
Assignees
Reporter
zhangjunphy
Clang seems to believe these two additions produce the same result and will optimize away the later one. However this is incorrect due to the `__builtin_set_flt_rounds` call, potentially changing the rounding mode.
Input:
```
void f(float a, float b, float *d, float *e) {
*d = a + b;
__builtin_set_flt_rounds(2);
*e = a + b;
}
```
ir:
```
define dso_local void @f(float, float, float*, float*)(float noundef %a, float noundef %b, ptr noundef writeonly captures(none) initializes((0, 4)) %d, ptr noundef writeonly captures(none) initializes((0, 4)) %e) local_unnamed_addr {
entry:
%add = fadd float %a, %b
store float %add, ptr %d, align 4
tail call void @llvm.set.rounding(i32 2)
store float %add, ptr %e, align 4
ret void
}
```
godbolt: https://godbolt.org/z/aaKnhvqMj
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140240] false positives of bugprone-sizeof-expression with a plain template type argument
Issue
140240
Summary
false positives of bugprone-sizeof-_expression_ with a plain template type argument
Labels
clang-tidy,
false-positive
Assignees
Reporter
sfc-gh-sgiesecke
When a template like
```
template
void unalignedStore(void* const dst, const T& src) noexcept {
std::memcpy(dst, &src, sizeof(T));
}
```
is instantiated with `Foo*` such that `Foo` is an aggregate, then this produces a diagnostic of `bugprone-sizeof-_expression_`:
```
error: suspicious usage of 'sizeof(A*)' on pointer-to-aggregate type; did you mean 'sizeof(A)'?
```
I'd say that it generally makes sense to emit a warning if the sizeof _expression_ is of the form `sizeof(T)` where `T` is a template type argument.
In addition, even if it makes sense, the diagnostic is not too helpful, as it doesn't mention the context of instantiation or the actual template type argument. `A*/A` is just a placeholder, which is generally confusing.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140241] cursor.extent or clang_getCursorExtent() crashes on TRANSLATION_UNIT cursor on macOS, but works on Linux
Issue
140241
Summary
cursor.extent or clang_getCursorExtent() crashes on TRANSLATION_UNIT cursor on macOS, but works on Linux
Labels
new issue
Assignees
Reporter
zokrezyl
# Title:
`clang_getCursorExtent()` crashes on TRANSLATION_UNIT cursor on macOS but works on Linux
## Description:
When calling `clang_getCursorExtent()` on a `CursorKind.TRANSLATION_UNIT` cursor, and then accessing `.start` or `.end` of the resulting `CXSourceRange`, a **segmentation fault occurs on macOS**.
This happens **consistently across**:
- **Python versions**: 3.11, 3.12, 3.13, and 3.14
- **Clang versions**: 18.x.y and 19.x.y (built from Homebrew or official sources)
- **macOS versions**: (tested on macOS 14.4+ Apple Silicon and Intel)
## Reproducer (Python `clang.cindex` bindings):
```python
from clang import cindex
cindex.Config.set_library_file("/opt/homebrew/opt/llvm/lib/libclang.dylib") # adjust if needed
index = cindex.Index.create()
tu = index.parse("example.cpp", args=["-std=c++17"]) # file contains `int main() { return 0; }`
cursor = tu.cursor # this is of kind TRANSLATION_UNIT
# These work:
print(cursor.kind)
print(cursor.spelling)
print(cursor.location)
# This also works (struct is returned)
print(cursor.extent.ptr_data)
print(cursor.extent.begin_int_data)
print(cursor.extent.end_int_data)
# But this crashes:
print(cursor.extent.start) # or `.end` → causes a segmentation fault on macOS
```
On Linux, this behaves safely — `extent.start.file` may be `None`, but no crash occurs.
## C-level Reproducer:
```c
CXIndex index = clang_createIndex(0, 0);
CXTranslationUnit tu = clang_parseTranslationUnit(index, "example.cpp", NULL, 0, NULL, 0, CXTranslationUnit_None);
CXCursor cursor = clang_getTranslationUnitCursor(tu);
CXSourceRange range = clang_getCursorExtent(cursor);
CXSourceLocation start = clang_getRangeStart(range); // 💥 Segfaults on macOS
```
## Expected Behavior
`clang_getCursorExtent()` should never return a `CXSourceRange` that causes `clang_getRangeStart()` or `clang_getRangeEnd()` to crash, even for synthetic cursors like `TRANSLATION_UNIT`.
If no valid extent exists, it should:
- return a dummy or sentinel range, or
- document that `.extent` is unsafe to access on certain kinds (not currently documented in `libclang`)
## Notes
- This crash does not occur when calling `.extent.start` on normal entities like functions, structs, typedefs, etc.
- The bug only affects the `TRANSLATION_UNIT` cursor, which is returned by `clang_getTranslationUnitCursor()`.
- The Python `clang.cindex` binding merely exposes the crash; the underlying issue is in `clang_getRangeStart()` accessing bad memory.
## Suggested Fix
Either:
- Have `clang_getCursorExtent()` return a well-defined dummy `CXSourceRange` for `TRANSLATION_UNIT`, or
- Have `clang_getRangeStart()` gracefully reject invalid or synthetic ranges, or
- Document that `TRANSLATION_UNIT` has no valid range
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140257] [OpenMP] Assertion `detail::isPresent(Val) && "dyn_cast on a non-existent value"' failed.
Issue
140257
Summary
[OpenMP] Assertion `detail::isPresent(Val) && "dyn_cast on a non-existent value"' failed.
Labels
new issue
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/zs3xzac18
```c
#include
void foo () {
int i;
#pragma omp target device (omp_is_initial_device)
i++;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140271] [X86] X86ISD::FP_TO_SINT_SAT/FP_TO_UINT_SAT are incorrectly defined in the MEMORY_OPCODE block
Issue 140271 Summary [X86] X86ISD::FP_TO_SINT_SAT/FP_TO_UINT_SAT are incorrectly defined in the MEMORY_OPCODE block Labels backend:X86 Assignees Reporter RKSimon ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140234] [X86[ Failure to merge shuffles of __m128d[2] back into single __m256d load
Issue
140234
Summary
[X86[ Failure to merge shuffles of __m128d[2] back into single __m256d load
Labels
backend:X86
Assignees
RKSimon
Reporter
RKSimon
```cpp
__m256d gg(__m128d x[2], __m128d y[2]) {
return (__m256d) {x[0][1], y[0][0], x[1][1], y[1][0]};
}
```
clang -march=avx
```asm
gg: # @gg
# %bb.0: # %entry
vmovapd (%rsi), %xmm0
vmovupd (%rdi), %ymm1
vmovddup %ymm0, %ymm0 # ymm0 = ymm0[0,0,2,2]
vinsertf128 $1, 16(%rsi), %ymm0, %ymm0
vshufpd $7, %ymm0, %ymm1, %ymm0 # ymm0 = ymm1[1],ymm0[1],ymm1[3],ymm0[2]
retq
# -- End function
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140258] [ClangCL] Incompatible behavior of explicit template instantiation combined with dllexport
Issue
140258
Summary
[ClangCL] Incompatible behavior of explicit template instantiation combined with dllexport
Labels
new issue
Assignees
Reporter
kikairoya
MSVC does not apply dllexport on explicit template instantiation definition to its inner class but able to override by attaching dllexport explicitly to inner class itself using explicit template instantiation.
Clang-cl emulates former behavior but not latter.
To reproduce:
```c++
template
struct outer_template {
static void fn_outer();
struct inner_class {
static void fn_inner();
};
};
template
void outer_template::fn_outer() { }
template
void outer_template::inner_class::fn_inner() { }
template struct __declspec(dllexport) outer_template;
```
Compile above with `> cl /FA /Fatest.asm /c test.cc` produces:
```asm
; Listing generated by Microsoft (R) Optimizing Compiler Version 19.44.35207.1
include listing.inc
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
PUBLIC ?fn_outer@?$outer_template@H@@SAXXZ ; outer_template::fn_outer
PUBLIC ??4?$outer_template@H@@QEAAAEAU0@AEBU0@@Z ; outer_template::operator=
PUBLIC ??4?$outer_template@H@@QEAAAEAU0@$$QEAU0@@Z ; outer_template::operator=
PUBLIC ?fn_inner@inner_class@?$outer_template@H@@SAXXZ ; outer_template::inner_class::fn_inner
; Function compile flags: /Odtp
; COMDAT ?fn_inner@inner_class@?$outer_template@H@@SAXXZ
_TEXT SEGMENT
?fn_inner@inner_class@?$outer_template@H@@SAXXZ PROC ; outer_template::inner_class::fn_inner, COMDAT
; File D:\tmp\test.cc
; Line 11
ret 0
?fn_inner@inner_class@?$outer_template@H@@SAXXZ ENDP ; outer_template::inner_class::fn_inner
_TEXT ENDS
(snip)
; Function compile flags: /Odtp
; COMDAT ?fn_outer@?$outer_template@H@@SAXXZ
_TEXT SEGMENT
?fn_outer@?$outer_template@H@@SAXXZ PROC ; outer_template::fn_outer, COMDAT
; File D:\tmp\test.cc
; Line 9
ret 0
?fn_outer@?$outer_template@H@@SAXXZ ENDP ; outer_template::fn_outer
_TEXT ENDS
END
```
Asm shows outer_template::inner_class::fn_inner was instantiated but `> cl test.cc /LD && objdump -p test.dll` shows
```
(snip)
[Ordinal/Name Pointer] Table -- Ordinal Base 1
Ordinal Hint Name
[ 0] +base[ 1] ??4?$outer_template@H@@QEAAAEAU0@$$QEAU0@@Z
[ 1] +base[ 2] 0001 ??4?$outer_template@H@@QEAAAEAU0@AEBU0@@Z
[ 2] +base[ 3] 0002 ?fn_outer@?$outer_template@H@@SAXXZ
The Function Table (interpreted .pdata section contents)
(snip)
```
means outer_template::inner_class::fn_inner was instantiated but NOT exported. (this is the former described behavior).
In case of clang-cl, `> clang-cl /FA /Fa6.asm /c test.cc` shows
```asm
(snip)
.def "?fn_outer@?$outer_template@H@@SAXXZ";
.scl 2;
.type 32;
.endef
.section .text,"xr",discard,"?fn_outer@?$outer_template@H@@SAXXZ"
.globl "?fn_outer@?$outer_template@H@@SAXXZ" # -- Begin function ?fn_outer@?$outer_template@H@@SAXXZ
.p2align 4
"?fn_outer@?$outer_template@H@@SAXXZ": # @"?fn_outer@?$outer_template@H@@SAXXZ"
# %bb.0:
ret
# -- End function
.def "?fn_inner@inner_class@?$outer_template@H@@SAXXZ";
.scl 2;
.type 32;
.endef
.section .text,"xr",discard,"?fn_inner@inner_class@?$outer_template@H@@SAXXZ"
.globl "?fn_inner@inner_class@?$outer_template@H@@SAXXZ" # -- Begin function ?fn_inner@inner_class@?$outer_template@H@@SAXXZ
.p2align 4
"?fn_inner@inner_class@?$outer_template@H@@SAXXZ": # @"?fn_inner@inner_class@?$outer_template@H@@SAXXZ"
# %bb.0:
ret
# -- End function
.section .drectve,"yni"
.ascii " /DEFAULTLIB:libcmt.lib"
.ascii " /DEFAULTLIB:oldnames.lib"
.ascii " /EXPORT:\"??4?$outer_template@H@@QEAAAEAU0@AEBU0@@Z\""
.ascii " /EXPORT:\"??4?$outer_template@H@@QEAAAEAU0@$$QEAU0@@Z\""
.ascii " /EXPORT:\"?fn_outer@?$outer_template@H@@SAXXZ\""
.addrsig
```
says outer_template::inner_class::fn_inner was instantiated but not exported correctly.
In contrast, modifying to
```
(snip)
template struct __declspec(dllexport) outer_template::inner_class;
template struct __declspec(dllexport) outer_template;
```
results by MSVC
```
(snip)
[Ordinal/Name Pointer] Table -- Ordinal Base 1
Ordinal Hint Name
[ 0] +base[ 1] ??4?$outer_template@H@@QEAAAEAU0@$$QEAU0@@Z
[ 1] +base[ 2] 0001 ??4?$outer_template@H@@QEAAAEAU0@AEBU0@@Z
[ 2] +base[ 3] 0002 ??4inner_class@?$outer_template@H@@QEAAAEAU01@$$QEAU01@@Z
[ 3] +base[ 4] 0003 ??4inner_class@?$outer_template@H@@QEAAAEAU01@AEBU01@@Z
[ 4] +base[ 5] 0004 ?fn_inner@inner_class@?$outer_template@H@@SAXXZ
[ 5] +base[ 6] 0005 ?fn_outer@?$outer_template@H@@SAXXZ
The Function Table (interpreted .pdata section contents)
(snip)
```
says outer_template::inner_class::fn_inner was exported (latter described behavior) but compiling with clang-cl shows error
```
test.cc(13,17): error: an attribute l
[llvm-bugs] [Bug 140259] [mlir] Inconsistent output when executing MLIR program with `--scf-parallel-loop-fusion`
Issue
140259
Summary
[mlir] Inconsistent output when executing MLIR program with `--scf-parallel-loop-fusion`
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: ba631508ae7f
system: `Ubuntu 18.04.6 LTS`
## Description:
I am experiencing an inconsistent result when executing the same MLIR program with and without `--scf-parallel-loop-fusion`.
## Steps to Reproduce:
### 1. **MLIR Program (a.mlir)**:
a.mlir:
```
module {
func.func private @printMemrefI32(tensor<*xi32>)
func.func private @printMemrefF32(tensor<*xf32>)
func.func @main() {
%idx0 = index.constant 0
%1 = "tosa.const"() <{values = dense<-5857> : tensor<1x4x4xi32>}> : () -> tensor<1x4x4xi32>
%10 = tosa.clz %1 : (tensor<1x4x4xi32>) -> tensor<1x4x4xi32>
%28 = tosa.cast %10 : (tensor<1x4x4xi32>) -> tensor<1x4x4xf32>
%48 = tosa.floor %28 : (tensor<1x4x4xf32>) -> tensor<1x4x4xf32>
%55 = tosa.reverse %48 {axis = 1 : i32} : (tensor<1x4x4xf32>) -> tensor<1x4x4xf32>
%cast_5 = tensor.cast %55 : tensor<1x4x4xf32> to tensor<*xf32>
call @printMemrefF32(%cast_5) : (tensor<*xf32>) -> ()
return
}
}
```
### 2. **Command to Run without `--scf-parallel-loop-fusion` :**
```
/pathto/mlir-opt a.mlir -tosa-to-scf -tosa-to-arith \
| /pathto/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" \
| /pathto/mlir-opt -convert-scf-to-cf --cse \
-one-shot-bufferize="bufferize-function-boundaries" -finalize-memref-to-llvm -convert-linalg-to-parallel-loops \
-convert-scf-to-cf -finalize-memref-to-llvm-convert-math-to-llvm -convert-arith-to-llvm \
-convert-index-to-llvm -convert-cf-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts \
| timeout 10 /pathto/mlir-cpu-runner -e main -entry-point-result=void \
--shared-libs=/pathto/libmlir_c_runner_utils.so \
--shared-libs=/pathto/libmlir_runner_utils.so \
--shared-libs=/pathto/libmlir_async_runtime.so
```
### 3. **Output without `--scf-parallel-loop-fusion` :**:
```
Unranked Memref base@ = 0x55a554495b40 rank = 3 offset = 0 sizes = [1, 4, 4] strides = [16, 4, 1] data =
""0,0,0],
[0,0,0,0],
[0,0, 0,0],
[0,0,0,0]]]
```
### 4. **Command to Run with `--scf-parallel-loop-fusion` :**
```
/pathto/mlir-opt a.mlir -tosa-to-scf -tosa-to-arith \
| /pathto/mlir-opt -pass-pipeline="builtin.module(func.func(tosa-to-linalg))" \
| /pathto/mlir-opt -convert-scf-to-cf --cse \
-one-shot-bufferize="bufferize-function-boundaries" -finalize-memref-to-llvm -convert-linalg-to-parallel-loops \
--scf-parallel-loop-fusion -convert-scf-to-cf -finalize-memref-to-llvm -convert-math-to-llvm -convert-arith-to-llvm \
-convert-index-to-llvm -convert-cf-to-llvm -convert-func-to-llvm -reconcile-unrealized-casts \
| timeout 10 /pathto/mlir-cpu-runner -e main -entry-point-result=void \
--shared-libs=/pathto/libmlir_c_runner_utils.so \
--shared-libs=/pathto/libmlir_runner_utils.so \
--shared-libs=/pathto/libmlir_async_runtime.so
```
### 5. **Output with `--scf-parallel-loop-fusion` :**
```
Unranked Memref base@ = 0x5625e8d1c780 rank = 3 offset = 0 sizes = [1, 4, 4] strides = [16, 4, 1] data =
""7.20647e+31,2.89575e+32,2.48354e+27],
[5.12554e-11,2.63753e+23,7.00624e+22,5.61567e+13],
[0,0, 0,0],
[0,0,0,0]]]
```
### 6. **Analysis for this case :**
This issue can be consistently reproduced by enabling the `--scf-parallel-loop-fusion` option, which fuses the last two `scf.parallel` loops.
I'm not sure whether the root cause lies in the `--scf-parallel-loop-fusion` transformation itself or in the subsequent `-convert-cf-to-llvm` lowering.
For reference:
[input.txt](https://github.com/user-attachments/files/20254061/input.txt)
contains the IR before applying `--scf-parallel-loop-fusion`.
[output.txt](https://github.com/user-attachments/files/20254107/output.txt)
contains the IR after applying `--scf-parallel-loop-fusion`.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140262] aarch64: -mcpu= passes -mcpu= instead of -march= to as with -no-integrated-as unlike GCC
Issue 140262 Summary aarch64: -mcpu= passes -mcpu= instead of -march= to as with -no-integrated-as unlike GCC Labels new issue Assignees Reporter pinskia GCC was changed this behavior almost 10 years ago: https://gcc.gnu.org/pipermail/gcc-patches/2015-August/426507.html . The reason is because GNU binutils and GCC are seperate projects so an older binutils can be used with a newer GCC without any issues. Plus it allows for GCC to use a different assembler besides GNU binutils which might not have that specific -mcpu option. clang should do the same. Right now `-no-integrated-as -mcpu=oryon-1` is broken when using with clang and GNU binutils' as because of this . `oryon-1` was not added to GNU binutils because it was not needed for when use with GCC; in fact there are other most other `-mcpu=` options have not been added to GNU binutils for this same reason. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140281] acc wait copy(x) causes fatal internal error: CHECK(!dirContext_.empty())
Issue 140281 Summary acc wait copy(x) causes fatal internal error: CHECK(!dirContext_.empty()) Labels flang, openacc Assignees Reporter erichkeane See this reproducer: ``` ! Type your code here, or load an example. integer function square(x) implicit none integer, intent(in) :: x !$acc wait copy(x) square = x * x end function square ``` ``` fatal internal error: CHECK(!dirContext_.empty()) failed at /root/llvm-project/flang/lib/Semantics/resolve-directives.cpp(60) PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /opt/compiler-explorer/clang-llvmflang-trunk/bin/flang -fc1 -fopenacc -emit-fir -o /app/output.s #0 0x03e3ce98 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x3e3ce98) #1 0x03e3aa54 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #2 0x7f8f50c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #3 0x7f8f50c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #4 0x7f8f50c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #5 0x7f8f50c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #6 0x05b2c0b9 (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x5b2c0b9) #7 0x04c9fe7d Fortran::semantics::AccAttributeVisitor::ResolveAccObjectList(Fortran::parser::AccObjectList const&, Fortran::semantics::Symbol::Flag) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4c9fe7d) #8 0x04cb7733 void Fortran::parser::detail::ParseTreeVisitorLookupScope::Walk(std::__cxx11::list> const&, Fortran::semantics::AccAttributeVisitor&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4cb7733) #9 0x04cd37d6 void Fortran::parser::detail::ParseTreeVisitorLookupScope::Walk(std::__cxx11::list> const&, Fortran::semantics::AccAttributeVisitor&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4cd37d6) #10 0x04cd65b8 void Fortran::parser::detail::ParseTreeVisitorLookupScope::Walk, Fortran::parser::SpecificationPart, Fortran::parser::ExecutionPart, std::optional, Fortran::parser::Statement>(std::tuple, Fortran::parser::SpecificationPart, Fortran::parser::ExecutionPart, std::optional, Fortran::parser::Statement> const&, Fortran::semantics::AccAttributeVisitor&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4cd65b8) #11 0x04cd72b0 Fortran::semantics::ResolveAccParts(Fortran::semantics::SemanticsContext&, Fortran::parser::ProgramUnit const&, Fortran::semantics::Scope*) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4cd72b0) #12 0x049421db Fortran::semantics::ResolveNamesVisitor::Pre(Fortran::parser::ProgramUnit const&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x49421db) #13 0x04943731 Fortran::semantics::ResolveNames(Fortran::semantics::SemanticsContext&, Fortran::parser::Program const&, Fortran::semantics::Scope&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4943731) #14 0x049b0e86 Fortran::semantics::Semantics::Perform() (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x49b0e86) #15 0x03e95998 Fortran::frontend::FrontendAction::runSemanticChecks() (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x3e95998) #16 0x04146be0 Fortran::frontend::CodeGenAction::beginSourceFileAction() (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x4146be0) #17 0x03e945d5 Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x3e945d5) #18 0x03e830d7 Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x3e830d7) #19 0x03e9e433 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x3e9e433) #20 0x021b50ae fc1_main(llvm::ArrayRef, char const*) (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x21b50ae) #21 0x0206c80f main (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x206c80f) #22 0x7f8f50c29d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90) #23 0x7f8f50c29e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40) #24 0x021b39d5 _start (/opt/compiler-explorer/clang-llvmflang-trunk/bin/flang+0x21b39d5) Program terminated with signal: SIGSEGV Compiler returned: 139 ``` https://godbolt.org/z/z8Wr7o8vj ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listin
[llvm-bugs] [Bug 140358] crash report
Issue 140358 Summary crash report Labels new issue Assignees Reporter felinepunch warning: overriding the module target triple with x86_64-pc-windows-msvc19.44.35207 [-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: "C:\\Program Files\\LLVM\\bin\\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.44.35207 -emit-obj -mincremental-linker-compatible -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name cleanup.ll -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -fms-volatile -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -fdebug-compilation-dir=C:\\Users\\cozy.vh\\OneDrive\\\271\256\274\2552\\llvm -fcoverage-compilation-dir=C:\\Users\\cozy.vh\\OneDrive\\\271\256\274\2552\\llvm -resource-dir "C:\\Program Files\\LLVM\\lib\\clang\\20" -ferror-limit 19 -fmessage-length=120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.44.35207 -fskip-odr-check-in-gmf -fdelayed-template-parsing -fcolor-diagnostics -faddrsig -o C:\\Users\\cozy.vh\\AppData\\Local\\Temp\\cleanup-bb58b2.o -x ir cleanup.ll 1. Code generation 2. Running pass 'Function Pass Manager' on module 'cleanup.ll'. 3. Running pass 'Exception handling preparation' on function '@f' Exception Code: 0xC005 #0 0x7ff7d66ce1d4 (C:\Program Files\LLVM\bin\clang.exe+0x2ce1d4) #1 0x7ff7d80e8791 (C:\Program Files\LLVM\bin\clang.exe+0x1ce8791) #2 0x7ff7d68f1694 (C:\Program Files\LLVM\bin\clang.exe+0x4f1694) #3 0x7ff7d7ddcad4 (C:\Program Files\LLVM\bin\clang.exe+0x19dcad4) #4 0x7ff7d6783411 (C:\Program Files\LLVM\bin\clang.exe+0x383411) #5 0x7ff7d6782de6 (C:\Program Files\LLVM\bin\clang.exe+0x382de6) #6 0x7ff7d677c9e2 (C:\Program Files\LLVM\bin\clang.exe+0x37c9e2) #7 0x7ff7d6b494df (C:\Program Files\LLVM\bin\clang.exe+0x7494df) #8 0x7ff7d6427ef3 (C:\Program Files\LLVM\bin\clang.exe+0x27ef3) #9 0x7ff7d6427b62 (C:\Program Files\LLVM\bin\clang.exe+0x27b62) #10 0x7ff7d6424f36 (C:\Program Files\LLVM\bin\clang.exe+0x24f36) #11 0x7ff7d6421a4d (C:\Program Files\LLVM\bin\clang.exe+0x21a4d) #12 0x7ff7d642033e (C:\Program Files\LLVM\bin\clang.exe+0x2033e) #13 0x7ff7d6868b4a (C:\Program Files\LLVM\bin\clang.exe+0x468b4a) #14 0x7ff7d6865583 (C:\Program Files\LLVM\bin\clang.exe+0x465583) #15 0x7ff7d834a384 (C:\Program Files\LLVM\bin\clang.exe+0x1f4a384) #16 0x7ffa502e7374 (C:\WINDOWS\System32\KERNEL32.DLL+0x17374) #17 0x7ffa50dfcc91 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x4cc91) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 20.1.0 Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\Program Files\LLVM\bin clang: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. command: clang cleanup.ll [cleanup.zip](https://github.com/user-attachments/files/20262917/cleanup.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140349] [clang] Assertion `hasAggregateEvaluationKind(E->getType()) && "Invalid argument!"' failed.
Issue
140349
Summary
[clang] Assertion `hasAggregateEvaluationKind(E->getType()) && "Invalid argument!"' failed.
Labels
Assignees
Reporter
k-arrows
Reproducer:
https://godbolt.org/z/5nz1o6GMz
```c
#include
void foo (int s, ...)
{
va_list ap;
va_start (ap, s);
int e = va_arg (ap, int()) ();
va_end (ap);
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140348] [clang] Crash in constexpr evaluator when initializing complex value
Issue
140348
Summary
[clang] Crash in constexpr evaluator when initializing complex value
Labels
clang
Assignees
Reporter
tbaederr
See:
```c++
typedef __attribute__((__ext_vector_type__(2))) float float2;
struct vec2 {
_Complex float v;
public:
constexpr vec2(float x, float y) {
__real(v) = x;
}
};
constexpr vec2 S = vec2(1.0, 1.0);
```
https://godbolt.org/z/Grds7av5Y
The [original report](https://github.com/llvm/llvm-project/pull/101126#issuecomment-2887852032) used vectors, but it also happens with the not-so-recent `_Complex`.
Backtrace:
```console
clang++: /root/llvm-project/llvm/tools/clang/lib/AST/ExprConstant.cpp:4071: typename SubobjectHandler::result_type findSubobject({anonymous}::EvalInfo&, const clang::Expr*, const {anonymous}::CompleteObject&, const {anonymous}::SubobjectDesignator&, SubobjectHandler&) [with SubobjectHandler = {anonymous}::ModifySubobjectHandler; typename SubobjectHandler::result_type = bool]: Assertion `O->isComplexFloat()' 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++20
1. :12:34: current parser token ';'
#0 0x03f99d48 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f99d48)
#1 0x03f979d4 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x3f979d4)
#2 0x03edc608 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x70c8a7842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x70c8a78969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x70c8a7842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x70c8a78287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x70c8a782871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x70c8a7839e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x078c3013 handleAssignment((anonymous namespace)::EvalInfo&, clang::Expr const*, (anonymous namespace)::LValue const&, clang::QualType, clang::APValue&) ExprConstant.cpp:0:0
#10 0x078f7ead clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#11 0x078f888d EvaluateLValue(clang::Expr const*, (anonymous namespace)::LValue&, (anonymous namespace)::EvalInfo&, bool) ExprConstant.cpp:0:0
#12 0x078cc266 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#13 0x078ccc14 EvaluateIgnoredValue((anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#14 0x078efdfc EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) (.part.0) ExprConstant.cpp:0:0
#15 0x078f0228 EvaluateStmt((anonymous namespace)::StmtResult&, (anonymous namespace)::EvalInfo&, clang::Stmt const*, clang::SwitchCase const*) (.part.0) ExprConstant.cpp:0:0
#16 0x07921593 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#17 0x0792195f HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140203] [Clang] -Wmissing-constinit triggers when the suggested change causes compilation error
Issue 140203 Summary [Clang] -Wmissing-constinit triggers when the suggested change causes compilation error Labels clang Assignees Reporter horenmar I have a header that declares a `constinit const` array, and a cpp file that initializes it with `constexpr` (because I want to be able to use it in further constexpr functions in that cpp file). This triggers `-Wmissing-constinit` pointed at the initializing declaration, together with a suggestion to add `constinit` to the declaration. However, doing so leads to a compilation error, because `constexpr` and `constinit` cannot be combined on a single declaration. [CE link](https://godbolt.org/z/4r4Y9G9db). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140205] Unnecessary -Wunused-value warning for fold expression with empty pack
Issue
140205
Summary
Unnecessary -Wunused-value warning for fold _expression_ with empty pack
Labels
new issue
Assignees
Reporter
svensandberg
The fold _expression_ in the following program produces the warning `_expression_ result unused [-Wunused-value]` (https://godbolt.org/z/715deezdG) in clang 5.0.0 and up (verified on 20.0.1):
```
#include
#include
template
std::string concat(Args &&...args) {
std::ostringstream out;
(out << ... << args);
return out.str();
}
int main() {
std::cout << concat();
}
```
I assume the reason is that when no arguments are passed to the function, the fold _expression_ reduces to the _expression_ `(out)`. If we had used the syntax `(out)` alone, the warning would be valid. But this code is meaningful when passing arguments to the function, and it would be useful to allow no arguments without warnings.
Workaround: `std::ignore = (out << ... << args)`.
Similar: https://github.com/llvm/llvm-project/issues/45124
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140209] [clangd] Cannot build the module if it's declared in a file with `.ixx` extension
Issue 140209 Summary [clangd] Cannot build the module if it's declared in a file with `.ixx` extension Labels new issue Assignees Reporter SidneyCogdill Like another [bug](https://github.com/llvm/llvm-project/issues/139189), this bug is discovered when working with C++ module support for the ["Proxy"](https://github.com/microsoft/proxy) library. I've created a [tiny project](https://github.com/SidneyCogdill/clangd_modules_bug_showcase/tree/clangd_ixx_bug) to demonstrate the bug. Pull the project using the following command: ```sh git clone \ --single-branch \ --branch clangd_ixx_bug \ --recursive \ https://github.com/SidneyCogdill/clangd_modules_bug_showcase.git ``` (Note: It's a good security practice to audit the project before opening it in your editor) The module file `proxy.ixx` exposes the interfaces in global fragment. It cannot be built by clangd when the module file ends with `.ixx` file extension. Renaming it to `proxy.cpp` or `proxy.cppm` fixes the issue. This bug only affects clangd. Clang can build the module without any issue. clangd version: ``` ~> clangd-21 --version Ubuntu clangd version 21.0.0 (++20250501084208+9b1051281e43-1~exp1~20250501084221.26) Features: linux+grpc Platform: x86_64-pc-linux-gnu ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140212] [clang-include-cleaner] __attribute__((__cleanup__())) function declaration detection doesn't work if hidden behind a macro
Issue 140212 Summary [clang-include-cleaner] __attribute__((__cleanup__())) function declaration detection doesn't work if hidden behind a macro Labels clang-include-cleaner Assignees Reporter DaanDeMeyer In systemd, we define the following macro: ```c #define _cleanup_(x) __attribute__((__cleanup__(x))) ``` This breaks the integration for `__cleanup__` that I added in #138669. The problem is caused by this bit of code in Analysis.cpp: ```cpp auto FID = SM.getFileID(SM.getSpellingLoc(Loc)); if (FID != SM.getMainFileID() && FID != SM.getPreambleFileID()) return; ``` The location passed in `VisitCleanupAttr()` doesn't map to either the main file ID or the preamble file ID. I assume this happens because we only have a location for the cleanup attribute which is mapped back to the macro. But we don't seem to have a location for the function decl that's in the cleanup macro. Otherwise I'd pass in that location and expect things to work but that doesn't seem to be an option. Happy to work on a fix, I just don't have a clue what the best way to fix this would be. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140217] Compiler crash
Issue 140217 Summary Compiler crash Labels new issue Assignees Reporter flirjakob [2025-05-16T07:03:53.513Z] PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. [2025-05-16T07:03:53.513Z] #0 0x010a188c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x10a188c) [2025-05-16T07:03:53.513Z] #1 0x0109f29e llvm::sys::RunSignalHandlers() (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x109f29e) [2025-05-16T07:03:53.513Z] #2 0x010a20af SignalHandler(int) Signals.cpp:0:0 [2025-05-16T07:03:53.513Z] #3 0x74d6471ab420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) [2025-05-16T07:03:53.513Z] #4 0x025d9705 (anonymous namespace)::EarlyCSE::run() EarlyCSE.cpp:0:0 [2025-05-16T07:03:53.513Z] #5 0x025d7fe4 llvm::EarlyCSEPass::run(llvm::Function&, llvm::AnalysisManager&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x25d7fe4) [2025-05-16T07:03:53.513Z] #6 0x0216c23d llvm::detail::PassModel >::run(llvm::Function&, llvm::AnalysisManager&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #7 0x03254060 llvm::PassManager >::run(llvm::Function&, llvm::AnalysisManager&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x3254060) [2025-05-16T07:03:53.513Z] #8 0x0212eb0d llvm::detail::PassModel >, llvm::PreservedAnalyses, llvm::AnalysisManager >::run(llvm::Function&, llvm::AnalysisManager&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #9 0x02c5ff1f llvm::CGSCCToFunctionPassAdaptor::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x2c5ff1f) [2025-05-16T07:03:53.513Z] #10 0x02173a2d llvm::detail::PassModel, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #11 0x02c5c081 llvm::PassManager, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x2c5c081) [2025-05-16T07:03:53.513Z] #12 0x0212e52d llvm::detail::PassModel, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, llvm::PreservedAnalyses, llvm::AnalysisManager, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #13 0x02c5e59c llvm::DevirtSCCRepeatedPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x2c5e59c) [2025-05-16T07:03:53.513Z] #14 0x0217488d llvm::detail::PassModel, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #15 0x02c5d648 llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x2c5d648) [2025-05-16T07:03:53.513Z] #16 0x0212e7dd llvm::detail::PassModel >::run(llvm::Module&, llvm::AnalysisManager&) PassBuilder.cpp:0:0 [2025-05-16T07:03:53.513Z] #17 0x032532fc llvm::PassManager >::run(llvm::Module&, llvm::AnalysisManager&) (/home/jenkins/workspace/workspace/Atlas-Gcc_Atlas-Gcc_PR-4803/.conan/data/emsdk/3.1.7/_/_/package/2880313eadc30db92089af7733fe8364772ee5c8/bin/upstream/bin/wasm-ld+0x32532fc) [2025-05-16T07:03:53.513Z] #18 0x0233c8d9 llvm::ModuleInlinerWrapperPass::run(llvm::Module&, llvm::AnalysisMa
[llvm-bugs] [Bug 140219] [AMDGPU] Use reverse iteration in CGP
Issue 140219 Summary [AMDGPU] Use reverse iteration in CGP Labels new issue Assignees Pierre-vh Reporter Pierre-vh #64591 has been fixed, so once the dust settles a bit (at least until the change propagates to downstream branches and we don't have any major issues) we can move forward with: - Removing all of the i16 promotion logic from CGP, deleting the option and removing/reworking associated tests - Use a reverse iteration order in the pass so it works like a normal combiner. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140220] clang-format, Inconsistent formatting with BraceWrapping.AfterControlStatement: MultiLine for single-line and multi-line if conditions
Issue
140220
Summary
clang-format, Inconsistent formatting with BraceWrapping.AfterControlStatement: MultiLine for single-line and multi-line if conditions
Labels
clang-format
Assignees
Reporter
halcyonx
Tested with: clang-format version 20.1.3 (https://github.com/llvm/llvm-project 923a5c4f83d2b3675bb88e9fe441daeaa4d69488)
Using BraceWrapping.AfterControlStatement: MultiLine leads to inconsistent formatting between single-line and multi-line if statements, which creates a visual inconsistency in codebases that use the compact if (cond) {} style.
```yaml
BraceWrapping:
AfterControlStatement: MultiLine
```
```cpp
if (!flag1) {
return;
}
if (flag2)
{
return;
}
```
If a codebase uses AfterControlStatement: Never and all if statements were consistent, it may still be desirable to apply AfterControlStatement: MultiLine for multi-line if conditions only, while keeping AfterControlStatement: Never for all other cases.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 140215] InstCombine pass wrongly removes va_start/va_end
Issue
140215
Summary
InstCombine pass wrongly removes va_start/va_end
Labels
new issue
Assignees
Reporter
hongjia
Test program:
``` C
typedef __builtin_va_list va_list;
#define va_start(ap, param) __builtin_va_start(ap, param)
#define va_end(ap) __builtin_va_end(ap)
#define va_arg(ap, type) __builtin_va_arg(ap, type)
#define va_copy(d, s) __builtin_va_copy(d, s)
int foo(int n, ...)
{
va_list ap, aq;
int x;
va_start(ap, n);
va_copy(aq, ap);
va_end(ap);
x = va_arg(aq, int);
va_end(aq);
return x + n;
}
```
Compile it with -O1:
```
clang -S -emit-llvm -O1 ic-va.c -mllvm --debug-_only_=instcombine
...
IC: Visiting: call void @llvm.va_copy.p0(ptr nonnull %aq, ptr nonnull %ap)
IC: Visiting: call void @llvm.va_end.p0(ptr %ap)
IC: ERASE call void @llvm.va_start.p0(ptr nonnull %ap)
ADD DEFERRED: %ap = alloca ptr, align 2
IC: ERASE call void @llvm.va_end.p0(ptr %ap)
...
```
The resulting IR:
```
...
; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn
define dso_local i32 @foo(i32 noundef %n, ...) local_unnamed_addr #0 {
entry:
%ap = alloca ptr, align 2
%aq = alloca ptr, align 2
call void @llvm.lifetime.start.p0(i64 2, ptr nonnull %ap) #3
call void @llvm.lifetime.start.p0(i64 2, ptr nonnull %aq) #3
call void @llvm.va_copy.p0(ptr nonnull %aq, ptr nonnull %ap)
%0 = va_arg ptr %aq, i32
call void @llvm.va_end.p0(ptr %aq)
%add = add nsw i32 %0, %n
call void @llvm.lifetime.end.p0(i64 2, ptr nonnull %aq) #3
call void @llvm.lifetime.end.p0(i64 2, ptr nonnull %ap) #3
ret i32 %add
}
...
```
%ap is used in va_copy() without being initialized.
For now I use the following ugly patch to fix this:
```
diff --git a/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp b/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
index c88710214e7e..d83228ae4b7e 100644
--- a/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
@@ -808,7 +808,10 @@ removeTriviallyEmptyRange(IntrinsicInst &EndI, InstCombinerImpl &IC,
IC.eraseInstFromFunction(*I);
IC.eraseInstFromFunction(EndI);
return true;
-}
+ } else if (EndI.getIntrinsicID() == Intrinsic::vaend &&
+ I->getIntrinsicID() == Intrinsic::vacopy &&
+ I->getArgOperand(1) == EndI.getArgOperand(0))
+ break;
// Skip start intrinsics that don't pair with this end intrinsic.
continue;
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
