[llvm-bugs] [Bug 123055] lldb-dap for VSCode ignoring env
Issue
123055
Summary
lldb-dap for VSCode ignoring env
Labels
new issue
Assignees
Reporter
nashiradeer
The lldb-dap VSCode's extension isn't setting the environment variables from my launch.json.
```json
{
"type": "lldb-dap",
"request": "launch",
"name": "Debug (lldb-dap)",
"program": "${workspaceFolder}/target/debug/hydrogen",
"preLaunchTask": "rust: cargo build",
"cwd": "${workspaceRoot}",
"env": {
"RUST_LOG": "hydrogen=trace",
},
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123033] [clang] Ambiguity between function declaration and definition when using pack indexing
Issue
123033
Summary
[clang] Ambiguity between function declaration and definition when using pack indexing
Labels
clang
Assignees
Reporter
FSK-idk
Godbolt: https://godbolt.org/z/817Kve9zc
It seems that clang can't compile code if I decide to separate the declaration and implementation of a function with pack indexing in some cases. However, if you comment out the declaration, it will compile.
```cpp
#include
#include
// in requires _expression_
template
requires std::same_as
void print(double d);
template
requires std::same_as
void print(double d) {
std::cout << "it doesn't work " << static_cast(d) << "\n";
}
// in return type
template
Types...[0] convert(double d);
template
Types...[0] convert(double d) {
return static_cast(d);
}
int main() {
print(12.34);
std::cout << "convert: " << convert(12.34) << "\n";
return 0;
}
```
Output
```
:30:5: error: call to 'print' is ambiguous
30 | print(12.34);
| ^~~
:9:6: note: candidate function [with Types = ]
9 | void print(double d);
| ^
:13:6: note: candidate function [with Types = ]
13 | void print(double d) {
| ^
:31:33: error: call to 'convert' is ambiguous
31 | std::cout << "convert: " << convert(12.34) << "\n";
| ^
:21:13: note: candidate function [with Types = ]
21 | Types...[0] convert(double d);
| ^
:24:13: note: candidate function [with Types = ]
24 | Types...[0] convert(double d) {
| ^
2 errors generated.
Compiler returned: 1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123052] Call to consteval method from constexpr constructor makes constructor consteval.
Issue
123052
Summary
Call to consteval method from constexpr constructor makes constructor consteval.
Labels
new issue
Assignees
Reporter
IViktorov
```C++
#include
#include
template
struct Test {
constexpr Test(const Test& t) noexcept: m_data{t.data()}, m_size{t.size()} {}
constexpr Test(T (&data)[kSize]) noexcept: m_data{data}, m_size{kSize} {}
constexpr T* data() const noexcept { return m_data; }
#ifdef NOCONSTEVAL
constexpr static std::size_t size() noexcept { return kSize; }
#else
consteval static std::size_t size() noexcept { return kSize; }
#endif
private:
T* m_data;
std::size_t m_size;
};
int main() {
int arr[] = {1, 2, 3, 4, 5, 6};
Test t1{arr};
Test t{t1};
std::println("arr[0] = {}, arr size = {}.", *t.data(), t.size());
}
```
With `consteval size()` method `Test` copy constructor becomes immediate function, but it should not.
Without consteval with `constexpr size()` everything goes as expected.
GCC doesn't have that problem with consteval methods, called in contructors.
https://godbolt.org/z/P157TafW8
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123041] Add a `--verbose` option for `llvm-strip`
Issue 123041 Summary Add a `--verbose` option for `llvm-strip` Labels new issue Assignees Reporter fxmarty-amd Hi, it appears `llvm-strip` has no `--verbose` option https://llvm.org/docs/CommandGuide/llvm-strip.html. `strip` utility has it and it proves handy. It would be nice to have a verbose option for `llvm-strip` to see which sections/symbols are removed. In my case, trying to use `llvm-objdump --syms` or `llvm-objdump -TC` I am unable to see a difference although the file size is reduced. Thank you! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123029] Assert triggered in AArch64ISelLowering::targetShrinkDemandedConstant when using half precision
Issue
123029
Summary
Assert triggered in AArch64ISelLowering::targetShrinkDemandedConstant when using half precision
Labels
new issue
Assignees
Reporter
WillFroom
I am emitting machine code using half precision for arm but I am hitting the following [assert](/github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp#L2376):
```cpp
assert((Size == 32 || Size == 64) &&
"i32 or i64 is expected after legalization.");
```
I have create a reproducible example: https://godbolt.org/z/d5aa5cxrK
I think it is possible that the assert is wrong, I believe it may just be there to check the following logic is correct:
```cpp
unsigned NewOpc;
switch (Op.getOpcode()) {
default:
return false;
case ISD::AND:
NewOpc = Size == 32 ? AArch64::ANDWri : AArch64::ANDXri;
break;
case ISD::OR:
NewOpc = Size == 32 ? AArch64::ORRWri : AArch64::ORRXri;
break;
case ISD::XOR:
NewOpc = Size == 32 ? AArch64::EORWri : AArch64::EORXri;
break;
}
```
which could be updated to check for `Size <= 32`: use `W` registers else use the `X` registers, I can create a PR for this change if someone can confirm I am correct, thanks!
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123030] Add break after assignment to format multiline expressions
Issue 123030 Summary Add break after assignment to format multiline expressions Labels new issue Assignees Reporter Ren911 In our project we want an option to break after first assignment with multiline statements For example, if _expression_ doesn’t fit on a single line, we add a break after assignment. ### Example 1 ``` anytype result = veelvaaarrriiiaabbblleeenam + seccconnnddverrryyylnnnggvarriaabbleeenamm + orjustalotofvariablesinvolvedinoneassignment; ``` The _expression_ above should become [like in this stackoverflow question](https://stackoverflow.com/questions/59235609/clang-format-multiline-variable-assignments) ``` anytype result = veelvaaarrriiiaabbblleeenam + seccconnnddverrryyylnnnggvarriaabbleeenamm + orjustalotofvariablesinvolvedinoneassignment; ``` ### Example 2 ``` anytype result = some_long_function_with_arguments(arg1, arg2, arg3); ``` should become ``` anytype result = some_long_function_with_arguments(arg1, arg2, arg3); ``` ### What exists now in clang-format? An option _AlwaysBreakBeforeMultilineStrings_ already exists in clang-format, and we want something similar, not only strings.  ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123142] clang-format indents class member functions oddly if there are function-like macro invocations
Issue
123142
Summary
clang-format indents class member functions oddly if there are function-like macro invocations
Labels
clang-format
Assignees
Reporter
alanzhao1
Given
```cpp
class PA_LOCKABLE Lock {
public:
void Acquire() PA_EXCLUSIVE_LOCK_FUNCTION() {}
void Release() PA_UNLOCK_FUNCTION() {}
};
```
where `PA_LOCKABLE`, `PA_EXCLUSIVE_LOCK_FUNCTION()`, and `PA_UNLOCK_FUNCTION()` are macros,
clang-format returns
```cpp
class PA_LOCKABLE Lock{
public : void Acquire() PA_EXCLUSIVE_LOCK_FUNCTION(){} void Release()
PA_UNLOCK_FUNCTION(){}
};
```
The main issues are:
* A space is added before and after the colon after `public`
* The space is removed between the class name and the curly bracket
* Very strange indentation and newlining of the two member functions
This regression occurred somewhere between 10664813fca8d5ccbfd90bae9e791b7062dabd7c and 29ed6000d21edd1a88b2daad242e1f356cafbaca
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123153] Clang does not warn about missing returns when a switch statement covers all enum values
Issue
123153
Summary
Clang does not warn about missing returns when a switch statement covers all enum values
Labels
clang
Assignees
Reporter
jeremy-rifkin
The following code triggers a missing return warning by gcc, msvc, and edg but not clang:
```cpp
enum class E { a, b };
int foo(E e) {
switch(e) {
case E::a:
return 20;
case E::b:
return 30;
}
}
```
https://godbolt.org/z/b5r34nWf6
The main issue here is safety: This code is bug-prone due to extraneous enum values. The most common situation this could lead to bugs is for flag enums, e.g. https://godbolt.org/z/zx6nnPYMq.
Secondarily: This can lead to some annoyances where code compiles fine on clang but has a flood of warnings on gcc (possibly fatal ones, if using -Werror=return-type). This leads to PRs such as https://github.com/llvm/llvm-project/pull/122382 and https://github.com/llvm/llvm-project/pull/105520.
I'd like to propose changing the behavior to warn on this case by default. I briefly discussed this with folks on the llvm discord as well: https://discord.com/channels/636084430946959380/636732781086638081/1329124923322531850.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123129] Clang Segmentation Fault When Instantiating a Template with Dynamic Array Initialization
Issue
123129
Summary
Clang Segmentation Fault When Instantiating a Template with Dynamic Array Initialization
Labels
clang
Assignees
Reporter
SOHAIBALOUSSI
this bug occurs when compiling C++ code with Clang 12.0.1 (Ubuntu 12.0.1-19ubuntu3):
A segfault is triggered during template instantiation when initializing a dynamic array in the constructor of a class template
```SQL
./Array.hpp:19:19: error: cannot determine allocated array size from initializer
arr = new T[]();
^
main.cpp:5:16: note: in instantiation of member function 'Array::Array' requested here
Array arr(10);
^
```
the bug arises when attempting to allocate an array with the following constructor signature in Array.hpp:
```c++
template
class Array {
public:
Array(size_t size) {
arr = new T[](); // Error: Cannot determine array size
}
};
```
the Clang compiler crashes with a segmentation fault, and the following stack dump is provided in the report
```
#0 0x7fa27317e2a1 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
...
#34 0x0040ea25 _start (/usr/lib/llvm-12/bin/clang+0x40ea25)
```
[main-7097c7.zip](https://github.com/user-attachments/files/18430962/main-7097c7.zip)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123151] [InstCombine] Miscompilation caused by incorrect ICMP predicate
Issue
123151
Summary
[InstCombine] Miscompilation caused by incorrect ICMP predicate
Labels
new issue
Assignees
Reporter
mshockwave
This is discovered from 445.gobmk when compiling it with RISC-V LLVM:
```
clang --target riscv64-linux-gnu -mcpu=sifive-p670 -O1 -mno-implicit-float ...
```
This is the reproducer snippet:
```llvm
define dso_local i1 @gg_sort.do.body.split(i32 %gap.0, i64 %width, ptr %base, ptr %div.out, ptr %add.ptr4.out, i64 noundef %nel) {
newFuncRoot:
%sub = add i64 %nel, -1
%mul = mul i64 %width, %sub
%add.ptr = getelementptr inbounds nuw i8, ptr %base, i64 %mul
br label %do.body.split
do.body.split:; preds = %newFuncRoot
%mul1 = mul nsw i32 %gap.0, 10
%add = add nsw i32 %mul1, 3
%div = sdiv i32 %add, 13
store i32 %div, ptr %div.out, align 4
%conv2 = sext i32 %div to i64
%mul3 = mul i64 %conv2, %width
%add.ptr4 = getelementptr inbounds nuw i8, ptr %base, i64 %mul3
store ptr %add.ptr4, ptr %add.ptr4.out, align 8
%cmp5.not21 = icmp ugt ptr %add.ptr4, %add.ptr
br i1 %cmp5.not21, label %for.end.exitStub, label %for.body.exitStub
for.end.exitStub: ; preds = %do.body.split
ret i1 true
for.body.exitStub: ; preds = %do.body.split
ret i1 false
}
```
With this command:
```
opt -p instcombine input.ll ...
```
The following code is generated:
```llvm
define dso_local i1 @gg_sort.do.body.split(i32 %gap.0, i64 %width, ptr %base, ptr %div.out, ptr %add.ptr4.out, i64 noundef %nel) {
newFuncRoot:
br label %do.body.split
do.body.split: ; preds = %newFuncRoot
%sub = add i64 %nel, -1
%mul = mul i64 %width, %sub
%mul1 = mul nsw i32 %gap.0, 10
%add = add nsw i32 %mul1, 3
%div = sdiv i32 %add, 13
store i32 %div, ptr %div.out, align 4
%conv2 = sext i32 %div to i64
%mul3 = mul i64 %width, %conv2
%add.ptr4 = getelementptr inbounds nuw i8, ptr %base, i64 %mul3
store ptr %add.ptr4, ptr %add.ptr4.out, align 8
%cmp5.not21 = icmp samesign ugt i64 %mul3, %mul
br i1 %cmp5.not21, label %for.end.exitStub, label %for.body.exitStub
for.end.exitStub: ; preds = %do.body.split
ret i1 true
for.body.exitStub: ; preds = %do.body.split
ret i1 false
}
```
InstCombine reduces ICMP on pointers (i.e. `%add.ptr` and `%add.ptr4`) into ICMP of their offsets (i.e. `%mul3` and `%mul`). I think the problem here is `%mul3` and `%mul` might have different signs.
Changing ICMP into sign comparison solves this issue: `%cmp5.not21 = icmp sgt i64 %mul3, %mul`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123144] clang-format produces unnecessary spacing around template angle brackets for class member function calls.
Issue
123144
Summary
clang-format produces unnecessary spacing around template angle brackets for class member function calls.
Labels
clang-tidy
Assignees
Reporter
alanzhao1
Given
```cpp
int foo() {
return bar()->baz<1 | 2>(1);
}
```
clang-format returns
```cpp
int foo() { return bar()->baz < 1 | 2 > (1); }
```
which has unnecessary spacing around the two angle brackets.
Things that are required to trigger this issue:
* Certain operators in the template parameter list trigger this issue (e.g. `|`, `&&`, and `&` work, but `+` doesn't)
* The `return` statement is required.
* There must be a parameter in the method call.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123139] Missed optimization(?): LLVM ignores carry flag after a 'shr'
Issue
123139
Summary
Missed optimization(?): LLVM ignores carry flag after a 'shr'
Labels
Assignees
Reporter
shelerr
https://godbolt.org/z/zdhPve74e
```
unsigned int bar1();
unsigned int bar2();
int foo(unsigned int num) {
unsigned int temp = num >> 12;
if ((num >> 11) % 2 == 0) {
return bar1() + temp;
} else {
return bar2() * temp;
}
}
```
```
foo(unsigned int):
pushrbx
mov ebx, edi
shr ebx, 12
testedi, 2048
jne .LBB0_2
callbar1()@PLT
add eax, ebx
pop rbx
ret
.LBB0_2:
callbar2()@PLT
imuleax, ebx
pop rbx
ret
```
On x86 64, 'shr' sets carry flag to the value of the last bit shifted out of the destination operand. So, I would expect the conditional jump to just be 'jc', insted of 'test'+'jne'. 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 123146] No code completion for member access operator when array-to-pointer decay is performed
Issue
123146
Summary
No code completion for member access operator when array-to-pointer decay is performed
Labels
clangd,
clang:frontend
Assignees
Reporter
ahatanak
$ cat test.c
```
struct my_foo {
int a;
int b;
};
struct my_foo arr[1];
void func() {
arr->
}
```
$ clang -cc1 -code-completion-at=test.c:9:8 test.c
If I declare `arr` as `struct my_foo *arr;`, code completion succeeds.
$ clang -cc1 -code-completion-at=test.c:9:8 test.c
COMPLETION: a : [#int#]a
COMPLETION: b : [#int#]b
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123163] Segfault
Issue
123163
Summary
Segfault
Labels
new issue
Assignees
Reporter
Kracken256
```py
Stack dump:
0. Program arguments: clang-tidy -format-style=file -header-filter=. pipeline/libnitrate-parser/src/core/ASTReader.cc -extra-arg=-std=c++20
1. parser at end of file
2. ASTMatcher: Processing 'modernize-use-constraints' against:
FunctionTemplateDecl boost::multiprecision::abs :
--- Bound Nodes Begin ---
function - { FunctionDecl boost::multiprecision::abs : }
functionTemplate - { FunctionTemplateDecl boost::multiprecision::abs : }
return - { DependentNameTypeLoc : }
--- Bound Nodes End ---
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 libLLVM.so.18.1 0x7b9c5f9a63bf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 63
1 libLLVM.so.18.1 0x7b9c5f9a44f9 llvm::sys::RunSignalHandlers() + 89
2 libLLVM.so.18.1 0x7b9c5f9a6b00
3 libc.so.6 0x7b9c5e445320
4 clang-tidy 0x56a042a0e035
5 clang-tidy 0x56a042a0d02b clang::tidy::modernize::UseConstraintsCheck::check(clang::ast_matchers::MatchFinder::MatchResult const&) + 155
6 clang-tidy 0x56a042d1ff15
7 clang-tidy 0x56a042d5300c clang::ast_matchers::internal::BoundNodesTreeBuilder::visitMatches(clang::ast_matchers::internal::BoundNodesTreeBuilder::Visitor*) + 156
8 clang-tidy 0x56a042d1f65f
9 clang-tidy 0x56a042d221eb
10 clang-tidy 0x56a042d2496b
11 clang-tidy 0x56a042d22747
12 clang-tidy 0x56a042d2496b
13 clang-tidy 0x56a042d22747
14 clang-tidy 0x56a042d4f6eb
15 clang-tidy 0x56a042d22b89
16 clang-tidy 0x56a042d22213
17 clang-tidy 0x56a042cf4825 clang::ast_matchers::MatchFinder::matchAST(clang::ASTContext&) + 709
18 libclang-cpp.so.18.1 0x7b9c68e42fbc clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) + 44
19 libclang-cpp.so.18.1 0x7b9c66f973d6 clang::ParseAST(clang::Sema&, bool, bool) + 598
20 libclang-cpp.so.18.1 0x7b9c68e0662c clang::FrontendAction::Execute() + 92
21 libclang-cpp.so.18.1 0x7b9c68d830b4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 708
22 libclang-cpp.so.18.1 0x7b9c68ffa6b9 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr, clang::FileManager*, std::shared_ptr, clang::DiagnosticConsumer*) + 425
23 clang-tidy 0x56a043373ab3
24 libclang-cpp.so.18.1 0x7b9c68ffa414 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr, std::shared_ptr) + 292
25 libclang-cpp.so.18.1 0x7b9c68ff917f clang::tooling::ToolInvocation::run() + 1231
26 libclang-cpp.so.18.1 0x7b9c68ffc1c1 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) + 5041
27 clang-tidy 0x56a04336fd9b clang::tidy::runClangTidy(clang::tidy::ClangTidyContext&, clang::tooling::CompilationDatabase const&, llvm::ArrayRef, std::allocator>>, llvm::IntrusiveRefCntPtr, bool, bool, llvm::StringRef) + 1083
28 clang-tidy 0x56a0426efc65 clang::tidy::clangTidyMain(int, char const**) + 10005
29 libc.so.6 0x7b9c5e42a1ca
30 libc.so.60x7b9c5e42a28b __libc_start_main + 139
31 clang-tidy 0x56a0426eafe5 _start + 37
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123164] Confusing CMake option related to llvm_runtime component compiler-rt
Issue 123164 Summary Confusing CMake option related to llvm_runtime component compiler-rt Labels new issue Assignees Reporter AugustineYang I have encountered an issue related to llvm_runtime component compiler-rt. When linking a riscv32 assembly code with ld.lld, I got an error saying `ld.lld: error: cannot open ../libclang_rt.builtins.a: No such file or directory`. After searching for previous issues like [#87150](https://github.com/llvm/llvm-project/issues/87150), [#72862](https://discourse.llvm.org/t/libclang-rt-builtins-a-is-not-being-built/72862), [How to build libclang_rt.builtins.a?](https://stackoverflow.com/questions/76936217/how-to-build-libclang-rt-builtins-a), it seems that the issue happens because of the lack of building "compiler-rt". After digging into the [Clang Doc](https://clang.llvm.org/docs/Toolchain.html#compiler-rt-llvm) and the CMakeLists file, it turns out that CMake option `-DLLVM_ENABLE_RUNTIMES=all` will only build default runtime components "libcxx;libcxxabi;libunwind" rather than all supported runtime components "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;offload". This can result in the possible omission of building the compiler-rt. Since many people have encountered the issue due to this confusing "all" options, maybe we should add a "default" option for building "default runtime components", and use "all" option to build "all supported runtime components". ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123165] Hexagon backend assertion "Decremented past the beginning of region to repair" in 7zIn.cpp
Issue
123165
Summary
Hexagon backend assertion "Decremented past the beginning of region to repair" in 7zIn.cpp
Labels
backend:Hexagon
Assignees
iajbar
Reporter
androm3da
clang++ asserts when compiling [7zIn.cpp's `CInArchive::GetNextFolderItem(CFolder &folder)`](https://github.com/llvm/llvm-test-suite/blob/1f917f95918479727e727c710348d9bf674588fc/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/7z/7zIn.cpp#L385) from `llvm-test-suite`:
```
hexagon-unknown-linux-musl-clang++: /local/mnt/workspace/upstream/toolchain_for_hexagon/llvm-project/llvm/lib/CodeGen/SlotIndexes.cpp:218: void llvm::SlotIndexes::repairIndexesInRange(MachineBasicBlock *, MachineBasicBlock::iterator, MachineBasicBlock::iterator): Assertion `ListI->getIndex() >= startIdx.getIndex() && (includeStart || !pastStart) && "Decremented past the beginning of region to repair."' failed.
```
I have reduced this failure to the test case below and bisected the failure to b6bf4024a031a5e7b58aff1425d94841a88002d6.
`./bin/llc --mtriple=hexagon -O2 ~/src/7z_20_0_0.ll --window-sched=off` does not assert.
Reduced failure context:
```
$ ./bin/llc --mtriple=hexagon -O2 ~/src/7z_20_0_0.ll
llc: /local/mnt/workspace/upstream/llvm-project/llvm/lib/CodeGen/SlotIndexes.cpp:218: void llvm::SlotIndexes::repairIndexesInRange(MachineBasicBlock *, MachineBasicBlock::iterator, MachineBasicBlock::iterator): Assertion `ListI->getIndex() >= startIdx.getIndex() && (includeStart || !pastStart) && "Decremented past the beginning of region to repair."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: ./bin/llc --mtriple=hexagon -O2 /usr2/bcain/src/7z_20_0_0.ll
...
```
`7z_20_0_0.ll`:
```
define void @_ZN10CInArchive17GetNextFolderItemEv(ptr %this) {
for.body.lr.ph.i:
br label %for.body.i.epil
for.body.i.epil: ; preds = %for.body.i.epil, %for.body.lr.ph.i
%epil.iter = phi i32 [ %epil.iter.next, %for.body.i.epil ], [ 0, %for.body.lr.ph.i ]
%0 = load ptr, ptr %this, align 8
%1 = load i8, ptr %0, align 1
%2 = load ptr, ptr null, align 8
store i8 %1, ptr %2, align 1
%epil.iter.next = add i32 %epil.iter, 1
%epil.iter.cmp.not = icmp eq i32 %epil.iter, 0
br i1 %epil.iter.cmp.not, label %for.body, label %for.body.i.epil
for.body.epil: ; preds = %for.body
%sub.epil = xor i32 %j.012, 0
store i32 %or911, ptr %this, align 4
ret void
for.body: ; preds = %for.body, %for.body.i.epil
%j.012 = phi i32 [ %inc.7, %for.body ], [ 0, %for.body.i.epil ]
%or911 = phi i32 [ %or.7, %for.body ], [ 0, %for.body.i.epil ]
%niter19 = phi i32 [ %niter19.next.7, %for.body ], [ 0, %for.body.i.epil ]
%or.7 = or i32 1, %j.012
%inc.7 = add i32 %j.012, 1
%niter19.next.7 = add i32 %niter19, 1
%niter19.ncmp.7 = icmp eq i32 %niter19, 0
br i1 %niter19.ncmp.7, label %for.body.epil, label %for.body
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123112] clang-format line breaking inconsistency
Issue
123112
Summary
clang-format line breaking inconsistency
Labels
clang-format
Assignees
Reporter
mikesreed
.\clang-format.exe --version
clang-format version 18.1.8 (https://github.com/llvm/llvm-project.git 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)
Using clang-format on the following code
```
class
{
(A, B, C, DDDCD&);
(A, B, C, DDDCDD);
(A, B, C, DDDCD& a);
(, , C, DDDCD& a);
};
class AAA
{
AAA(A, B, C, DDDCD&);
AAA(AA, B, C, DDDCD&);
};
```
gives the following results
```
class
{
(A, B, C, DDDCD&);
(
A,
B,
C,
DDDCDD
);
(
A,
B,
C,
DDDCD& a
);
(
,
,
C,
DDDCD& a
);
};
class AAA
{
AAA(A,
B,
C,
DDDCD&);
AAA(AA,
B,
C,
DDDCD&);
};
```
Why is that first ctor not broken like all the other ctors?
Attached the .clang-format file as clang-format.txt
[clang-format.txt](https://github.com/user-attachments/files/18429399/clang-format.txt)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123120] Missed shrink-wrap opportunity compared to GCC
Issue
123120
Summary
Missed shrink-wrap opportunity compared to GCC
Labels
missed-optimization
Assignees
Reporter
Kmeakin
https://godbolt.org/z/KjTe5PhMP
```c++
#include
#include
auto push_back(std::vector& xs, uint8_t x) -> void {
xs.push_back(x);
}
```
GCC moves the code for saving/restoring registers via the stack into the subsequent basic blocks, leaving the happy path free from stack traffic. LLVM sadly does not.
```asm
; GCC output:
push_back(std::vector >&, unsigned char):
ldp x2, x4, [x0, 8]
mov x3, x0
cmp x2, x4
beq .L2
strbw1, [x2]
ldr x0, [x0, 8]
add x0, x0, 1
str x0, [x3, 8]
ret
.L2:
; grow the vector ...
; LLVM output:
push_back(std::vector>&, unsigned char):
stp x29, x30, [sp, #-64]!
stp x24, x23, [sp, #16]
stp x22, x21, [sp, #32]
stp x20, x19, [sp, #48]
mov x29, sp
ldp x8, x9, [x0, #8]
mov x19, x0
cmp x8, x9
b.eq.LBB0_2
strbw1, [x8]
ldr x8, [x19, #8]
add x8, x8, #1
str x8, [x19, #8]
ldp x20, x19, [sp, #48]
ldp x22, x21, [sp, #32]
ldp x24, x23, [sp, #16]
ldp x29, x30, [sp], #64
ret
.LBB0_2:
; grow the vector ...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123066] clang-tidy - a dynamic_cast triggers clang-analyzer-core.CallAndMessage warning
Issue
123066
Summary
clang-tidy - a dynamic_cast triggers clang-analyzer-core.CallAndMessage warning
Labels
Assignees
Reporter
fekir
Consider following snippet (https://godbolt.org/z/nb9fheEjq)
#define USE_DYNAMIC_CAST
struct base{
virtual void foo();
virtual ~base();
};
struct derived:base{};
struct derived2:base{};
void bar(base* b){
#ifdef USE_DYNAMIC_CAST
auto* d = dynamic_cast(b);
if(d){
d->foo();
}
#endif
b->foo();
}
depending if `USE_DYNAMIC_CAST` is defined or not, clang-tidy triggers following warning
[:39:5: warning: Called C++ object pointer is null [clang-analyzer-core.CallAndMessage]]
39 | b->foo();
| ^
[:34:8: note: Assuming 'd' is null]
34 | if(d)
| ^
[:34:5: note: Taking false branch]
34 | if(d)
| ^
[:39:5: note: Called C++ object pointer is null]
39 | b->foo();
It seems to imply, that if `d` is `nullptr`, then also `b` must have been null, which is not true.
Removing the check `if(d)` also silences the warning, but since `b` does not necessarily point to a `derived` object, it would be the wrong thing to do.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123077] llvm-mc uses wrong ABI for RISC-V platform on Linux by default
Issue 123077 Summary llvm-mc uses wrong ABI for RISC-V platform on Linux by default Labels new issue Assignees Reporter directhex This is a related issue to https://github.com/llvm/llvm-project/issues/115679 and possibly https://github.com/llvm/llvm-project/issues/50591. Generally, the default ABI handling is done differently in every tool, where https://reviews.llvm.org/D69383 defined the current behaviour for clang. Roughly speaking, it is reasonable for a user to expect these two compiler invocations to act in an equivalent way: ``` $ clang -o bottles.o bottles.c ``` ``` $ clang -S -o bottles.S bottles.c $ llvm-mc --filetype=obj -o bottles.o bottles.S ``` However, they don't. Without use of the (undocumented) `-target-abi=lp64d` flag, `llvm-mc` targets a different ABI and the resulting object files cannot be linked with objects produced by `clang`/`clang++` Per the changes in D69383 to clang/lib/Driver/ToolChains/Arch/RISCV.cpp, the logic used by clang to this day is: ``` if (Triple.getOS() == llvm::Triple::UnknownOS) return "lp64"; else return "lp64d"; ``` i.e. use `lp64` unless a named OS is used, in which case use `lp64d`. Explicitly forcing an OS into the triple (i.e. passing `-triple riscv64-unknown-linux-gnu` to `llvm-mc`) does not result in the `clang` behaviour of defaulting to `lp64d` when calling `llvm-mc`. As time allows, I intend to try and get a PR filed to unify `llvm-mc`'s behaviour - I wanted to document the issue first. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123079] [AMDGPU][GISel] Missing FMAX3 use
Issue 123079 Summary [AMDGPU][GISel] Missing FMAX3 use Labels good first issue, backend:AMDGPU, llvm:globalisel Assignees Reporter qcolombet GISel fails to use the max3 (and probably min3) instruction on AMDGPU. Instead it uses a sequence of 2 max instructions. SDISel gets this right. I believe the AMDGPU port miss a port of the `SITargetLowering::performMinMaxCombine` optimization. # To Reproduce # Download the attached IR or copy/paste it from below. Then run: ```bash llc -O3 -march=amdgcn -mcpu=gfx942 -mtriple amdgcn-amd-hmcsa -global-isel=<0|1> repro.ll -o - ``` [repro.ll.txt](https://github.com/user-attachments/files/18427260/repro.ll.txt) # Result # GISel: ```asm s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) v_max_f32_e32 v0, v0, v0 v_max_f32_e32 v0, 0, v0 v_mov_b32_e32 v4, v1 v_mov_b32_e32 v5, v2 v_max_f32_e32 v0, 0, v0 flat_store_dword v[4:5], v0 s_waitcnt vmcnt(0) lgkmcnt(0) s_setpc_b64 s[30:31] ``` SDISel: ```asm s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) v_mov_b32_e32 v3, v2 v_mov_b32_e32 v2, v1 v_max3_f32 v0, v0, 0, 0 flat_store_dword v[2:3], v0 s_waitcnt vmcnt(0) lgkmcnt(0) s_setpc_b64 s[30:31] ``` GISel uses 3 `max` instructions where SDISel manages to do the same thing with just one `max3` instruction. Note: The test case was automatically reduced hence the input values constants are not representative of the real workload. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123085] cl : Command line warning D9025 when using AddLLVM.cmake on windows + msvc
Issue 123085 Summary cl : Command line warning D9025 when using AddLLVM.cmake on windows + msvc Labels new issue Assignees Reporter anmyachev The following lines are probably the reason for this: * https://github.com/llvm/llvm-project/blob/16e45b8fac797c6d4ba161228b54665492204a9d/llvm/cmake/modules/AddLLVM.cmake#L51 * https://github.com/llvm/llvm-project/blob/16e45b8fac797c6d4ba161228b54665492204a9d/llvm/cmake/modules/AddLLVM.cmake#L66 This is how `googletest` fixes this problem: https://github.com/google/googletest/pull/1612/files More details: https://github.com/google/googletest/issues/1611#issue-326697513 Warnings: ```bash cl : Command line warning D9025 : overriding '/EHs' with '/EHs-' cl : Command line warning D9025 : overriding '/EHc' with '/EHc-' cl : Command line warning D9025 : overriding '/GR' with '/GR-' ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123090] [flang] Incorrect diagnostic on component initialization using intrinsic function
Issue 123090 Summary [flang] Incorrect diagnostic on component initialization using intrinsic function Labels flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` PROGRAM main IMPLICIT NONE TYPE :: DT CHARACTER*(INT(ACOSD(0.5))) :: C=CHAR(INT(ACOSD(0.5))) END TYPE end ``` Flang currently issues an error as: ``` error: Semantic errors in a7.f ./a7.f:4:41: error: Must be a constant value CHARACTER*(INT(ACOSD(0.5))) :: C=CHAR(INT(ACOSD(0.5))) ^ ``` This seems wrong to me. All the intrinsic functions used in initialization can be folded at the compile time. All of ifort, gfortran and XLF compile the above code successfully. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123064] clang's -Wunreachable-code does not fire if the first unreachable line is a macro
Issue
123064
Summary
clang's -Wunreachable-code does not fire if the first unreachable line is a macro
Labels
clang:frontend
Assignees
Reporter
nico
This warns (as it should):
```
thakis@Mac src % cat notreach.cc
[[noreturn]] void notreached();
void g();
void f() {
notreached();
g();
}
% clang -c notreach.cc -Wunreachable-code
notreach.cc:6:3: warning: code will never be executed [-Wunreachable-code]
6 | g();
| ^
1 warning generated.
```
This doesn't:
```
% cat notreach2.cc
[[noreturn]] void notreached();
void g();
#define MY_MACRO(x) (void)(x)
void f() {
notreached();
MY_MACRO(5);
g();
}
% clang -c notreach2.cc -Wunreachable-code
# no output
```
Not emitting unreachable code warnings for the macro itself probably makes sense, but the diagnostic disappearing completely seems surprising.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123065] [AMDGPU][GISel] FMin fmax pattern not recognize
Issue
123065
Summary
[AMDGPU][GISel] FMin fmax pattern not recognize
Labels
llvm:globalisel
Assignees
Reporter
qcolombet
The attached reproducer lowers with compares and selects with GISel whereas SDISel uses fmin and fmax resulting in a shorter and more efficient code sequence.
SDISel seems to perform the simplification as part of its IR building process.
# To Reproduce #
Download the attached reproducer or copy/paste the IR below.
[repro.ll.txt](https://github.com/user-attachments/files/18426310/repro.ll.txt)
Then run:
```bash
llc -O3 -march=amdgcn -mcpu=gfx942 -mtriple amdgcn-amd-hmcsa -global-isel=<0|1> repro.ll -o -
```
# Result #
GISel:
```asm
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
v_and_b32_e32 v1, 1, v1
v_cmp_ne_u32_e32 vcc, 0, v1
v_mov_b32_e32 v1, 0x57f0
s_nop 0
v_cndmask_b32_e32 v0, 0, v0, vcc
v_cmp_le_f16_e32 vcc, v0, v1
s_nop 1
v_cndmask_b32_e32 v0, v1, v0, vcc
v_cvt_f32_f16_e32 v0, v0
v_cvt_i32_f32_e32 v2, v0
v_mov_b64_e32 v[0:1], 0
global_store_byte v[0:1], v2, off
s_waitcnt vmcnt(0)
s_setpc_b64 s[30:31]
```
SDISel:
```asm
s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
v_and_b32_e32 v1, 1, v1
v_cmp_eq_u32_e32 vcc, 1, v1
s_nop 1
v_cndmask_b32_e32 v0, 0, v0, vcc
v_max_f16_e32 v0, v0, v0
v_min_f16_e32 v0, 0x57f0, v0
v_cvt_i16_f16_e32 v2, v0
v_mov_b64_e32 v[0:1], 0
global_store_byte v[0:1], v2, off
s_waitcnt vmcnt(0)
s_setpc_b64 s[30:31]
```
# Note #
Input:
```llvm
target datalayout = "e-p:64:64-p1:64:64-p2:32:32-p3:32:32-p4:64:64-p5:32:32-p6:32:32-p7:160:256:256:32-p8:128:128-p9:192:256:256:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-S32-A5-G1-ni:7:8:9"
target triple = "amdgcn-amd-amdhsa"
define void @foo.bb848(<1 x half> %i888, <1 x i1> %0, <1 x i1> %1) {
newFuncRoot:
%i924 = select <1 x i1> %0, <1 x half> %i888, <1 x half> zeroinitializer
%.inv24 = fcmp ole <1 x half> %i924, splat (half 0xH57F0)
%i932 = select <1 x i1> %.inv24, <1 x half> %i924, <1 x half> splat (half 0xH57F0)
%i940 = fptosi <1 x half> %i932 to <1 x i8>
store <1 x i8> %i940, ptr addrspace(1) null, align 1
ret void
}
```
The problem was reduced to make it easier to debug, but the original issue was using a vector of size 4.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123069] RISC-V EVL tail folding
Issue
123069
Summary
RISC-V EVL tail folding
Labels
backend:RISC-V,
vectorizers
Assignees
Reporter
lukel97
On the spacemit-x60, [GCC 14 is ~24% faster on the 525.x264_r SPEC CPU 2017 benchmark than a recent build of Clang](https://lnt.lukelau.me/db_default/v4/nts/profile/13/18/15).
A big chunk of this difference is due to GCC tail folding its loops with VL, whereas LLVM doesn't by default.
Because LLVM doesn't tail fold its loops, it generates both a vectorized body and a scalar epilogue. There is a minimum trip count >= VF required to execute the vectorized body, otherwise it can only run the scalar epilogue.
On 525.x264_r, there are some very hot functions (e.g. `get_ref`) which never meet the minimum trip count and so the vector code is never ran. Tail folding avoids this issue and allows us to run the vectorized body every time.
There are likely other performance benefits to be had with tail folding with VL, so it seems worthwhile exploring.
"EVL tail folding" (LLVM's vector-predication terminology for VL tail folding), can be enabled from Clang with `-mllvm -prefer-predicate-over-epilogue=predicate-else-scalar-epilogue -mllvm -force-tail-folding-style=data-with-evl`. It initially landed in #76172 but it isn't enabled by default yet due to support for it not being fully complete, both in the loop vectorizer and elsewhere in the RISC-V backend.
This issue aims to track what work is needed across the LLVM project to bring it up to a stable state, at which point we can evaluate its performance to see if it should be enabled by default.
It's not a complete list and only contains the tasks that I've noticed so far. Please feel free to edit and add to it!
I presume we will find more things that need addressed as time goes on.
- [ ] Set up CI infrastructure for -force-tail-folding-style=data-with-evl
- [ ] Likely need a buildbot that runs llvm-test-suite in this configuration, similar to the [AArch64 sve2 buildbots](https://lab.llvm.org/buildbot/#/builders/198)
- [X] Igalia is running [nightly SPEC CPU 2017 benchmarking with EVL tail folding via LNT](https://lnt.lukelau.me/db_default/v4/nts/machine/26)
- [ ] Address known miscompiles
- #122461
- [ ] Fix cases that abort vectorization entirely
- On SPEC CPU 2017 as of 02403f4e450b86d93197dd34045ff40a34b21494, with EVL tail folding we vectorize 57% less loops that were previously vectorized. This is likely due to vectorization aborting when it encounters unimplemented cases:
- VPWidenIntOrFpInductionRecipe
- #115274
- #118638
- VPWidenPointerInductionRecipe
- Fixed-length VFs: There are cases where scalable vectorization isn’t possible and we currently don't allow fixed-length VFs, so presumably nothing gets vectorized in this case.
- Cases where the RISC-V cost model may have become unprofitable with EVL tail folding
- [ ] Implement support for EVL tail folding in other parts of the loop vectorizer
- [ ] Fixed-order recurrences (will fall back to DataWithoutLaneMask style after #122458)
- #100755
- #114205 (see note on RISCVVLOptimizer below)
- [ ] Extend RISC-V VP intrinsic codegen
- Segmented accesses #120490
- Strided accesses in RISCVGatherScatterLowering
- #122244
- #122232
- Eventually, the loop vectorizer should be taught to emit `vp.strided.{load,store}` intrinsics directly cc) @nikolaypanchenko
- [ ] RISCVVLOptimizer
- The VL optimizer may have made non-trapping VP intrinsics redundant. We should evaluate if we still need to transform intrinsics/calls/binops to VP intrinsics in the LV
- #91796
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123073] [clangd] LLVM-style Baremetal toolchain driver was selected for TUs built with `arm-none-eabi-gcc` GNU toolchain
Issue 123073 Summary [clangd] LLVM-style Baremetal toolchain driver was selected for TUs built with `arm-none-eabi-gcc` GNU toolchain Labels Assignees Reporter RigoLigoRLC Note: this issue is opened based on suggestion of clangd maintainer under clangd/clangd#2289. Specifics of the issue can also be found in the referred issue under clangd. I've been building an ARM microcontroller toolchain with `arm-none-eabi` GNU toolchain provided by ARM, and clangd was used for code completion. Clangd will consume `compile_commands.json` generated by CMake Ninja generator and provide completion and live error checks in Visual Studio Code. The issue is that, clangd will choose `clang::driver::toolchains::BareMetal` as the toolchain driver for translation units built by my GNU toolchain (for example `arm-none-eabi-gcc.exe`). Further inspection found that any toolchain that had neither an OS target nor an designated architecture will all cause `BareMetal` selected as the driver, which will lead to clangd looking for system headers in LLVM-style include paths rather than the correct GNU style. (See `clang/lib/Driver/Driver.cpp, Driver::getToolChain`.) Using `--query-driver` is said to be *the most robust way* of fixing these issues of cross-compilation toolchains but to me this seems like a bug (not handling GNU toolchain correctly). Also, having to add `--query-driver` option on every computer that has a different GCC installation path is not so practical either. RISC-V also has a special check for existence of GNU toolchain, and when a GNU toolchain is present then a GNU-style toolchain driver will be created. Clearly this is only fixing it for RISC-V, and ARM was not getting some love. I thin maybe the detection of GNU toolchain should be improved overall so that other architectures like Xtensa (used extensively in ESP32S3, for example) will also benefit, and maintainer on clangd side suggested that this topic may be more appropriately discussed on LLVM issue tracker. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123074] clang define `__cpp_pack_indexing` macro in both c++23 mode and c++20 mode
Issue 123074 Summary clang define `__cpp_pack_indexing` macro in both c++23 mode and c++20 mode Labels Assignees Reporter Arteiimis **whitch cause this issue**: https://github.com/fnc12/sqlite_orm/issues/1358 **godbolt**: https://godbolt.org/z/hs1KPfTrj **screen shot:**  **iknow clang defines some higher-version test macros even in lower c++ mode , but clang19 dosen't seem to support pack indexing yet still defines `cpp_pack_indexing`...** **test link**: https://godbolt.org/z/74davPM8c ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123075] [flang] CP2K fails to compile due to assertion 'result && "Fell off the end of a type-switch"'
Issue
123075
Summary
[flang] CP2K fails to compile due to assertion 'result && "Fell off the end of a type-switch"'
Labels
flang
Assignees
Reporter
pawosm-arm
I'm building CP2K from this SHA: https://github.com/cp2k/cp2k/commit/3905869e4cb94c1f9fc3fc3ecca6c77dece2aa01 since the next SHA (https://github.com/cp2k/cp2k/commit/4837b70ec08ad54fc946d169bea3b08710f565ab ) introduces a new code which flang cannot compile (see https://github.com/llvm/llvm-project/issues/108827 closed issue but the problem still occurs). Unfortunately, very late in the process, the compilation fails on the https://github.com/cp2k/cp2k/blob/master/src/transport.F file as such:
```
llvm/ADT/TypeSwitch.h:121: llvm::TypeSwitch::operator ResultT() [with T = mlir::Type; ResultT = {anonymous}::TargetAArch64::NRegs]: Assertion `result && "Fell off the end of a type-switch"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
```
Execution command line (including `fypp` preprocessing):
```
tools/build_utils/fypp -n src/transport.F transport.F90 mpifort -fno-backslash -c -D__FFTW3 -D__parallel -D__SCALAPACK -ffp-contract=fast -O3 -fopenmp -mcpu=native -ffree-form -D__COMPILE_ARCH="\"Linux-LLVM-flang\"" -D__COMPILE_DATE="\"Tue 14 Jan 23:36:31 UTC 2025\"" -D__COMPILE_HOST="\"host\"" -D__COMPILE_REVISION="\"git:3905869\"" -D__DATA_DIR="\"data\"" -D__SHORT_FILE__="\"transport.F\"" -I'src/' -I'obj/Linux-LLVM-flang/psmp/exts/dbcsr' transport.F90
```
The problem goes away after commenting out the following line: https://github.com/cp2k/cp2k/blob/f8b3abcd3ac413146004a9ebf8d71317c9449627/src/transport.F#L419
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123025] [LLDB] lldb-rpc-server stack overflow cause by recursive function calls
Issue 123025 Summary [LLDB] lldb-rpc-server stack overflow cause by recursive function calls Labels new issue Assignees Reporter wingfiring Environment: Apple M1 Pro, 32GB memory MacOS 14.6 (23G80) Xcode Version 15.2 (15C500b) lldb version lldb-1500.0.200.58 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5) I can't make a reasonable reproduce steps, but have a crash log, looks like a endless recursive function calls. ``` VM Region Info: 0x381bbbff0 is in 0x381bb8000-0x381bbc000; bytes after start: 16368 bytes before end: 15 REGION TYPESTART - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL Stack 3813b-381bb8000[ 8224K] rw-/rwx SM=PRV thread 7 ---> STACK GUARD 381bb8000-381bbc000[ 16K] ---/rwx SM=NUL stack guard for thread 8 Stack 381bbc000-3823c4000[ 8224K] rw-/rwx SM=PRV thread 8 ... 12 LLDB 0x1155cd390 lldb_private::ValueObjectSynthetic::ValueObjectSynthetic(lldb_private::ValueObject&, std::__1::shared_ptr) + 264 13 LLDB 0x1155c1938 lldb_private::ValueObject::CalculateSyntheticValue() + 156 14 LLDB 0x1155c1b54 lldb_private::ValueObject::HasSyntheticValue() + 44 15 LLDB 0x1155c3900 lldb_private::ValueObject::Dereference(lldb_private::Status&) + 580 16 LLDB 0x1155cd90c lldb_private::ValueObjectSynthetic::CreateSynthFilter() + 200 17 LLDB 0x1155cd390 lldb_private::ValueObjectSynthetic::ValueObjectSynthetic(lldb_private::ValueObject&, std::__1::shared_ptr) + 264 18 LLDB 0x1155c1938 lldb_private::ValueObject::CalculateSyntheticValue() + 156 19 LLDB 0x1155c1b54 lldb_private::ValueObject::HasSyntheticValue() + 44 20 LLDB 0x1155c3900 lldb_private::ValueObject::Dereference(lldb_private::Status&) + 580 21 LLDB 0x1155cd90c lldb_private::ValueObjectSynthetic::CreateSynthFilter() + 200 ``` [lldb-rpc-server.log](https://github.com/user-attachments/files/18421261/lldb-rpc-server.log) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123034] Using __llvm_profile_{get_size_for_buffer, write_buffer, reset_counters}() in freestanding environments
Issue
123034
Summary
Using __llvm_profile_{get_size_for_buffer,write_buffer,reset_counters}() in freestanding environments
Labels
new issue
Assignees
Reporter
royger
Hello,
I'm trying to use LLVM profiling on a kernel, and would like to export the data to a buffer using the provided `__llvm_profile_{get_size_for_buffer,write_buffer,reset_counters}()` helpers. I've declared external prototypes for them at the caller translation unit, and also defined `__llvm_profile_runtime` on that same translation unit as a global symbol.
However, when attempting to link the resulting object files together, I get the following errors:
```
# ld -melf_x86_64_fbsd -T arch/x86/xen.lds -N prelink.o --build-id=sha1 ./common/symbols-dummy.o -o ./.xen-syms.0
ld: error: undefined hidden symbol: __llvm_profile_get_size_for_buffer
>>> referenced by lib/xxhash64.c
>>> prelink.o:(get_size)
>>> referenced by lib/xxhash64.c
>>> prelink.o:(dump)
ld: error: undefined hidden symbol: __llvm_profile_reset_counters
>>> referenced by lib/xxhash64.c
>>> prelink.o:(reset_counters)
ld: error: undefined hidden symbol: __llvm_profile_write_buffer
>>> referenced by lib/xxhash64.c
>>> prelink.o:(dump)
```
I can kind of workaround those by adding the compiler_rt profiling library to the linker phase:
```
# ld /usr/lib/clang/19/lib/freebsd/libclang_rt.profile-x86_64.a -melf_x86_64_fbsd -T arch/x86/xen.lds -N prelink.o --build-id=sha1 ./common/symbols-dummy.o -o ./.xen-syms.0
ld: error: /usr/lib/clang/19/lib/freebsd/libclang_rt.profile-x86_64.a(InstrProfilingPlatformLinux.o):(function __llvm_write_binary_ids: .text+0xf3): relocation R_X86_64_PC32 out of range: 137644034653121 is not in [-2147483648, 2147483647]; references '__ehdr_start'
>>> referenced by InstrProfilingPlatformLinux.c:179 (/usr/src/contrib/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:179)
>>> defined in
ld: error: /usr/lib/clang/19/lib/freebsd/libclang_rt.profile-x86_64.a(InstrProfilingPlatformLinux.o):(function __llvm_write_binary_ids: .text+0x118): relocation R_X86_64_PC32 out of range: 137644034653028 is not in [-2147483648, 2147483647]; references '__ehdr_start'
>>> referenced by InstrProfilingPlatformLinux.c:0 (/usr/src/contrib/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:0)
>>> defined in
ld: error: /usr/lib/clang/19/lib/freebsd/libclang_rt.profile-x86_64.a(InstrProfilingPlatformLinux.o):(function __llvm_write_binary_ids: .text+0x11f): relocation R_X86_64_PC32 out of range: 137644034653053 is not in [-2147483648, 2147483647]; references '__ehdr_start'
>>> referenced by InstrProfilingPlatformLinux.c:0 (/usr/src/contrib/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:0)
>>> defined in
ld: error: /usr/lib/clang/19/lib/freebsd/libclang_rt.profile-x86_64.a(InstrProfilingPlatformLinux.o):(function __llvm_write_binary_ids: .text+0x19e): relocation R_X86_64_PC32 out of range: 137644034652894 is not in [-2147483648, 2147483647]; references '__ehdr_start'
>>> referenced by InstrProfilingPlatformLinux.c:0 (/usr/src/contrib/llvm-project/compiler-rt/lib/profile/InstrProfilingPlatformLinux.c:0)
>>> defined in
```
But that's ugly, as I don't know a programatic way to get the name and path of the required compiler_rt profiling library, neither does it solve the issue, as now there are undefined references to `__ehdr_start`. Is there some guidance I'm missing about how to use profiling on freestanding environments?
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123039] Unexpected interaction between ColumnLimit = 0 and BWACS_MultiLine
Issue
123039
Summary
Unexpected interaction between ColumnLimit = 0 and BWACS_MultiLine
Labels
new issue
Assignees
Reporter
semushin-s
Let's say we have the following config
```
BasedOnStyle: WebKit
ColumnLimit: 0
BreakBeforeBraces: Custom
BraceWrapping:
AfterControlStatement: MultiLine
```
As a result any of the following snippets do not change after formatting (as if it's ok to either wrap or not wrap the brace regardless of if being multilien):
```cpp
bool f(int b)
{
if (b)
{
return true;
}
return false;
}
```
```cpp
bool f(int b)
{
if (b) {
return true;
}
return false;
}
```
```cpp
bool f(int b)
{
if (b
&& true) {
return true;
}
return false;
}
```
```cpp
bool f(int b)
{
if (b
&& true)
{
return true;
}
return false;
}
```
I think the correct behaviour should be to consider control statement having any line breaks before formatting or not in such case.
If I'm not mistaken [here](https://github.com/llvm/llvm-project/blob/fb13e65acf0b7de3dd0b60b6312df07fdf9da652/clang/lib/Format/UnwrappedLineFormatter.cpp#L318) is the place where we check is statement multi line or not based on column limit only.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123038] missing parenthesis for function-like macro invocation could have better diagnostic
Issue 123038 Summary missing parenthesis for function-like macro invocation could have better diagnostic Labels clang:diagnostics Assignees Reporter zmodem Consider: ``` $ cat /tmp/a.c #define FOO() 42 int x = FOO; ``` The compiler will error because we forgot to use parens for `FOO`: ``` $ clang -c /tmp/a.c /tmp/a.c:2:9: error: use of undeclared identifier 'FOO' 2 | int x = FOO; | ^ 1 error generated. ``` It would be nice if the compiler diagnostic included a note pointing out that `FOO` does exist, but as a function-like macro it requires parenthesis. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123092] [AMDGPU][Attributor] OpenMC Performance Regression on AMD GPU
Issue 123092 Summary [AMDGPU][Attributor] OpenMC Performance Regression on AMD GPU Labels new issue Assignees Reporter jtramm I have observed a performance regression in the OpenMC scientific simulation application (which uses OpenMP target offloading) on the AMD MI250 due to commit https://github.com/llvm/llvm-project/commit/7dbd6cd2946ec3a9b4ad2dfd7ead177baac15bd7, which is part of PR #114357. The regression is not observed on NVIDIA GPUs. This commit causes OpenMC to be 20% slower overall on a typical benchmark problem, with the most expensive kernel in the simulation being about 2x slower. OpenMC can be installed and its performance benchmark run using the following script: https://github.com/jtramm/openmc_offloading_builder/tree/main FOM before this commit (higher is better): ``` Calculation Rate (inactive) = 239870.0 particles/second ``` FOM after this commit: ``` Calculation Rate (inactive) = 192707.0 particles/second ``` Main kernel timing before this commit: ``` XS lookups (Fuel) = 1.8720e+01 seconds ``` Main kernel after this commit: ``` XS lookups (Fuel) = 3.5231e+01 seconds ``` Rocprof shows similar slowdown for this kernel, which it lists as: ``` __omp_offloading_25_7c638f81__ZN6openmc32process_calculate_xs_events_fuelEv_l256.kd ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 123121] Audit/Update `select` uses in DiagnosticXKinds.td to use `enum_select`.
Issue 123121 Summary Audit/Update `select` uses in DiagnosticXKinds.td to use `enum_select`. Labels good first issue, clang:diagnostics Assignees Reporter erichkeane `enum_select` was added in this patch here: https://github.com/llvm/llvm-project/pull/122505 It is a really useful version of `select` that also creates an `enum` so that we don't have to use unreliable 'magic numbers'. However, the original patch touches one such diagnostic. We need someone to audit all of our uses of `select` and see if: 1- the `select` has a significant number of `items` in it. 2- A lot of the uses of the `select` for the diagnostic in the source use a lot of magic numbers, OR an enum-made-just-for it So if the diagnostic tends to have a lot of `/* ThingIWantSelected */ 5` sort of things (or worse, just the `5`!), it is likely a good candidate. Ones that are 'calculated' based on some other criteria aren't a great. One such example is from: https://github.com/llvm/llvm-project/pull/120327 , which is what encouraged this patch. Once we have ones identified, someone should then go through and convert these diagnostics. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
