[llvm-bugs] [Bug 120049] [clang++]Does clang++ support '-minline-stringops-dynamically' ?
Issue 120049 Summary [clang++]Does clang++ support '-minline-stringops-dynamically' ? Labels clang Assignees Reporter zhaojiangkun-1 I have no problem using `g++ -minline-stringops-dynamically`, but failed to compile with `clang++ --minline-stringops-dynamically`. Does clang++ support '-minline-stringops-dynamically' ? **error:** `clang-15: error: unknown argument: '-minline-stringops-dynamically'` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120050] clang-format v19.1.5 crash
Issue 120050 Summary clang-format v19.1.5 crash Labels clang-format Assignees Reporter haiboxia007 clang-format format "json.hpp" crash --- Error Informations from clang-format output Formatting [1/1] .\json.hpp LLVM ERROR: out of memory Allocation failed PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: C:\\DevTools\\bin\\clang-format --style=file -i --verbose .\\json.hpp Exception Code: 0xC01D LLVM ERROR: out of memory Allocation failed Formatting [1/1] .\json_fwd.hpp json.hpp from JSON for Modern C++, nlohmann-json https://github.com/nlohmann/json, single header, size: 919975 bytes ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120057] Support Full Path Matching for Process Selection in LLDB attach Command
Issue 120057 Summary Support Full Path Matching for Process Selection in LLDB attach Command Labels new issue Assignees Reporter suxiaogang223 Description: When attempting to use LLDB to attach to a process by name, I encountered a situation where multiple processes share the same name but differ in their full paths. LLDB currently only considers the process name, which leads to ambiguity and prevents me from attaching to the intended process. Here is the specific scenario: ```text Could not attach: more than one process named /mnt/disk2/suyiteng/output/be/lib/doris_be: PIDPARENT USER TRIPLE ARGUMENTS == == == == 1026195 1 suyiteng x86_64-*-linux-gnu /mnt/disk2/suyiteng/output21/be/lib/doris_be 3306900 1 suyiteng x86_64-*-linux-gnu /mnt/disk2/suyiteng/output/be/lib/doris_be ``` As shown, both processes are named doris_be, but their paths differ: 1. /mnt/disk2/suyiteng/output21/be/lib/doris_be 2. /mnt/disk2/suyiteng/output/be/lib/doris_be The paths provide a clear distinction between the two processes, and being able to select based on the full path would resolve this issue. Proposed Feature: Enhance the attach command to support full path matching for process selection. For example: • If provided with a full path, LLDB should match processes by their executable path. • If a partial path is provided, LLDB could match based on a substring of the path for additional flexibility. Benefit: This feature would significantly improve the usability of LLDB in environments where processes with the same name exist in different directories, which is a common scenario in development and debugging workflows. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120108] [clang][modules] Inline function incorrectly marked as hidden leads to undefined reference
Issue
120108
Summary
[clang][modules] Inline function incorrectly marked as hidden leads to undefined reference
Labels
clang,
clang:modules
Assignees
Reporter
ldionne
In some circumstances, functions are incorrectly given hidden visibility when Clang modules are enabled, which leads to undefined references. Here's a reproducer where we basically have two small header files, each of which is a module:
```c++
// construct_at:
template
constexpr void __construct_at(T* location, T arg) {
void* loc = __voidify(*location);
(void)loc;
}
```
```c++
// voidify
template
__attribute__((__always_inline__)) void* __voidify(T& from) {
return const_cast(static_cast(&from));
}
```
We then have a small test program that uses `construct_at`:
```c++
#include
void foo(int* ptr) {
__construct_at(ptr, 3);
}
```
Finally, we compile with modules enabled:
```
clang++ -std=c++17 -fmodules -fcxx-modules -fmodules-cache-path=ModuleCache.noindex -fbuiltin-module-map -c test.cpp -o test.o
```
And we can see that an undefined reference to `__voidify` is being generated in `test.o`, which should never happen for a few reasons:
1. It's a template, so we need to have a `linkonce_odr` definition in `test.o`
2. Even worse, it's marked as `always_inline` so it's absolutely evident that this can't end happily. Indeed, we know at the declaration that a definition will never be emitted anywhere else, so this is bound to fail.
In other words, this shouldn't create an undefined reference to `__voidify` regardless of whether that function is marked as `__always_inline__`, but it's just a bit more vexing that it does.
[Full reproducer](https://github.com/user-attachments/files/18153807/reproducer.zip) attached.
Also tracked as rdar://121551667.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120141] Clang -O2 generates wrong asm instructions.
Issue
120141
Summary
Clang -O2 generates wrong asm instructions.
Labels
clang
Assignees
Reporter
lomes0
### Env
```
clang-19 --version
Ubuntu clang version 19.1.5 (++20241203083330+ab4b5a2db582-1~exp1~20241203083345.68)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin
lsb_release -a ILPO-PRD-UBN156 llvm_passes * via C v11.4.0-gcc
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 22.04.4 LTS
Release:22.04
Codename: jammy
uname -a ILPO-PRD-UBN156 llvm_passes * via C v11.4.0-gcc
Linux ILPO-PRD-UBN156 6.8.0-49-generic #49~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Nov 6 17:42:15 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
```
### Details
O2 optimisations are yielding inccorect asm instructions.
Reporduction is simple, compile:
```bash
clang-19 -O2 -g -c -o buf.o buf.c
clang-19 -O2 -g -c -o main.o main.c
clang-19 -O2 -g -o main main.o buf.o
```
```c
// main.c
#include
#include
#include
#include "buf.h"
int
handler(void)
{
char *buf;
int len=0;
srand(time(NULL));
if (rand() & 0x1) {
build_buf (&buf, &len);
}
else {
printf("...");
}
send_buf (buf, len);
return 0;
}
int main()
{
(void) handler();
return 0;
}
```
```c
// buf.c
#include "buf.h"
void send_buf (char* buf,int len) {}
void build_buf (char** buf, int* len) { }
```
```c
// buf.h
void send_buf (char*, int);
void build_buf (char** buf, int* len);
```
The generated handler() asm skips the call to send_buf, whenever the if condition evalutes to false (ie. printf("...") is called).
See gdb for the exact asm:
```gdb
gdb main ILPO-PRD-UBN156 llvm_passes * via C v11.4.0-gcc
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from main...
(gdb) disassemble handler
Dump of assembler code for function handler:
0x1170 <+0>: sub$0x18,%rsp
0x1174 <+4>: movl $0x0,0xc(%rsp)
0x117c <+12>:xor%edi,%edi
0x117e <+14>:call 0x1050
0x1183 <+19>:mov%eax,%edi
0x1185 <+21>:call 0x1040
0x118a <+26>:call 0x1060
0x118f <+31>:test $0x1,%al
0x1191 <+33>:je 0x11b7
0x1193 <+35>:lea0x10(%rsp),%rdi
0x1198 <+40>:lea0xc(%rsp),%rsi
0x119d <+45>:call 0x11f0
0x11a2 <+50>:mov0x10(%rsp),%rdi
0x11a7 <+55>:mov0xc(%rsp),%esi
0x11ab <+59>:call 0x11e0
0x11b0 <+64>:xor%eax,%eax
0x11b2 <+66>:add$0x18,%rsp
0x11b6 <+70>:ret
0x11b7 <+71>:lea0xe46(%rip),%rdi# 0x2004
0x11be <+78>:xor%eax,%eax
0x11c0 <+80>:call 0x1030
End of assembler dump.
(gdb)
```
Notice handler<+33> jumps to handler+<71>.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120140] Assertion `i < NumContainedTys && "Index out of range!"' failed.
Issue
120140
Summary
Assertion `i < NumContainedTys && "Index out of range!"' failed.
Labels
new issue
Assignees
Reporter
wesuRage
`/usr/local/llvm-19/include/llvm/IR/Type.h:385: Type *llvm::Type::getContainedType(unsigned int) const: Assertion `i < NumContainedTys && "Index out of range!"' failed.
Aborted (core dumped)`
This shows up when I try to get the type contained in the pointer. Its used in the line:
```cpp
llvm::Type *ElementType = llvm::cast(SymbolValue->getType())->getContainedType(0);
```
line:
```cpp
llvm::Type *ElementType = llvm::cast(LType)->getContainedType(0);
```
and line:
```cpp
llvm::Type *ElementType = llvm::cast(RType)->getContainedType(0);
```
This is the full code for more context:
```cpp
#include "backend/generator/expressions/generate_binary_expr.hpp"
#include "backend/generator/expressions/generate_expr.hpp"
#include "backend/generator/symbols/identifier_symbol_table.hpp"
llvm::Value *generate_binary_expr(BinaryExprNode *node, llvm::LLVMContext &Context, llvm::IRBuilder<> &Builder, llvm::Module &Module) {
llvm::Value *L = generate_expr(node->left, Context, Builder, Module);
llvm::Value *R = generate_expr(node->right, Context, Builder, Module);
llvm::Type *LType = L->getType();
llvm::Type *RType = R->getType();
auto resolve_pointer = [&](llvm::Value *Val, llvm::Type *&Type, const std::string &name) -> llvm::Value * {
if (Type->isPointerTy()) {
llvm::Value *SymbolValue = find_identifier(name);
if (!SymbolValue) {
throw std::runtime_error("Symbol '" + name + "' not found in the symbol table.");
}
llvm::Type *ElementType = llvm::cast(SymbolValue->getType())->getContainedType(0);
if (!ElementType) {
throw std::runtime_error("Unable to determine the element type of the pointer for '" + name + "'.");
}
Val = Builder.CreateLoad(ElementType, Val, "load_" + name);
Type = ElementType;
}
return Val;
};
if (node->left->kind == NODE_IDENTIFIER) {
auto *LNameNode = static_cast(node->left->data);
L = resolve_pointer(L, LType, LNameNode->symbol);
}
if (node->right->kind == NODE_IDENTIFIER) {
auto *RNameNode = static_cast(node->right->data);
R = resolve_pointer(R, RType, RNameNode->symbol);
}
if (LType->isPointerTy()) {
llvm::Type *ElementType = llvm::cast(LType)->getContainedType(0);
if (!ElementType) {
throw std::runtime_error("Unable to determine the element type of the pointer.");
}
if (ElementType->isIntegerTy()) {
L = Builder.CreatePtrToInt(L, llvm::Type::getInt32Ty(Context), "ptr_to_int_L");
LType = llvm::Type::getInt32Ty(Context);
} else if (ElementType->isFloatingPointTy()) {
L = Builder.CreatePtrToInt(L, llvm::Type::getInt32Ty(Context), "ptr_to_int_L");
L = Builder.CreateSIToFP(L, llvm::Type::getDoubleTy(Context), "int_to_fp_L");
LType = llvm::Type::getDoubleTy(Context);
}
}
if (RType->isPointerTy()) {
llvm::Type *ElementType = llvm::cast(RType)->getContainedType(0);
if (!ElementType) {
throw std::runtime_error("Unable to determine the element type of the pointer.");
}
if (ElementType->isIntegerTy()) {
L = Builder.CreatePtrToInt(R, llvm::Type::getInt32Ty(Context), "ptr_to_int_L");
LType = llvm::Type::getInt32Ty(Context);
} else if (ElementType->isFloatingPointTy()) {
R = Builder.CreatePtrToInt(R, llvm::Type::getInt32Ty(Context), "ptr_to_int_L");
R = Builder.CreateSIToFP(R, llvm::Type::getDoubleTy(Context), "int_to_fp_L");
RType = llvm::Type::getDoubleTy(Context);
}
}
bool isLInteger = LType->isIntegerTy();
bool isRInteger = RType->isIntegerTy();
bool isLFloating = LType->isFloatingPointTy();
bool isRFloating = RType->isFloatingPointTy();
// Handle integer-specific operations
if (isLInteger && isRInteger) {
if (strcmp(node->op, "+") == 0) return Builder.CreateAdd(L, R, "addtmp");
if (strcmp(node->op, "-") == 0) return Builder.CreateSub(L, R, "subtmp");
if (strcmp(node->op, "*") == 0) return Builder.CreateMul(L, R, "multmp");
if (strcmp(node->op, "/") == 0) return Builder.CreateSDiv(L, R, "divtmp");
if (strcmp(node->op, "%") == 0) return Builder.CreateSRem(L, R, "modtmp");
if (strcmp(node->op, "&") == 0) return Builder.CreateAnd(L, R, "andtmp");
if (strcmp(node->op, "|") == 0) return Builder.CreateOr(L, R, "ortmp");
if (strcmp(node->op, "^") == 0) return Builder.CreateXor(L, R, "xortmp");
if (strcmp(node->op, ">>") == 0) return Builder
[llvm-bugs] [Bug 120148] [clang-format] Wrong formatting when template variable in last thing before closing parenthesis
Issue 120148 Summary [clang-format] Wrong formatting when template variable in last thing before closing parenthesis Labels clang-format Assignees Reporter vient ```cpp auto t1 = a + b; auto t2 = (b) + b; auto t3 = (a) + b; auto t4 = (a + 1) + b; ``` is formatted as ```cpp auto t1 = a + b; auto t2 = (b) + b; auto t3 = (a)+b; // wrong, no spaces around + auto t4 = (a + 1) + b; ``` https://godbolt.org/z/9K11MrPz9 `clang-format version 20.0.0git (https://github.com/llvm/llvm-project.git 8daf4f16fa08b5d876e98108721dd1743a360326)` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120151] [clang-tidy] Access violation
Issue 120151 Summary [clang-tidy] Access violation Labels clang-tidy Assignees Reporter GloryOfNight While running github actions job, clang-tidy crashed with following: ```llvm FAILED: CMakeFiles/udp-relay-static.dir/src/socket/win/internetaddrWin.cxx.obj "C:\Program Files\CMake\bin\cmake.exe" -E __run_co_compile --tidy="C:/Program Files/LLVM/bin/clang-tidy.exe;--extra-arg-before=--driver-mode=g++" --source=D:\a\udp-relay\udp-relay\src\socket\win\internetaddrWin.cxx -- C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -ID:/a/udp-relay/udp-relay/include -O3 -DNDEBUG -std=gnu++20 -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -MD -MT CMakeFiles/udp-relay-static.dir/src/socket/win/internetaddrWin.cxx.obj -MF CMakeFiles\udp-relay-static.dir\src\socket\win\internetaddrWin.cxx.obj.d -o CMakeFiles/udp-relay-static.dir/src/socket/win/internetaddrWin.cxx.obj -c D:/a/udp-relay/udp-relay/src/socket/win/internetaddrWin.cxx Error running 'C:/Program Files/LLVM/bin/clang-tidy.exe': PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: "C:/Program Files/LLVM/bin/clang-tidy.exe" --extra-arg-before=--driver-mode=g++ D:\\a\\udp-relay\\udp-relay\\src\\socket\\win\\internetaddrWin.cxx -- C:\\PROGRA~1\\LLVM\\bin\\CLANG_~1.EXE -ID:/a/udp-relay/udp-relay/include -O3 -DNDEBUG -std=gnu++20 -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -MD -MT CMakeFiles/udp-relay-static.dir/src/socket/win/internetaddrWin.cxx.obj -MF CMakeFiles\\udp-relay-static.dir\\src\\socket\\win\\internetaddrWin.cxx.obj.d -o CMakeFiles/udp-relay-static.dir/src/socket/win/internetaddrWin.cxx.obj -c D:/a/udp-relay/udp-relay/src/socket/win/internetaddrWin.cxx 1. parser at end of file 2. While analyzing stack: #0 Calling std::_Fmt_write(class std::back_insert_iterator >, const basic_string_view) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:3520:16 #1 Calling std::_Default_arg_formatter>, char>::operator()(class std::basic_string_view) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:799:20 #2 Calling std::basic_format_arg>, char>>::_Visit(struct std::_Default_arg_formatter >, char> &&) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:934:12 #3 Calling std::visit_format_arg(struct std::_Default_arg_formatter >, char> &&, basic_format_arg >, char> >) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:3625:25 #4 Calling std::_Format_handler::_On_replacement_field(const size_t, const char *) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:1485:9 #5 Calling std::_Parse_replacement_field(const char *, const char *, struct std::_Format_handler &) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:1551:18 #6 Calling std::_Parse_format_string(basic_string_view, struct std::_Format_handler &) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:3749:9 #7 Calling std::vformat_to(class std::back_insert_iterator >, const string_view, const format_args) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:3826:5 #8 Calling std::vformat(const string_view, const format_args) at line C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:3856:12 #9 Calling std::format(const format_string, char (&)[22], unsigned short &&) at line 37 #10 Calling internetaddrWin::toString() 3. C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:2585:33 : Error evaluating statement 4. C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.42.34433\include\format:2585:33 : Error evaluating statement Exception Code: 0xC005 #0 0x7ff663160b2e (C:\Program Files\LLVM\bin\clang-tidy.exe+0x17d0b2e) #1 0x7ff66373195b (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1da195b) #2 0x7ff662e07320 (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1477320) #3 0x7ff662e177a7 (C:\Program Files\LLVM\bin\clang-tidy.exe+0x14877a7) #4 0x7ff6631b4db1 (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1824db1) #5 0x7ff6631b7661 (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1827661) #6 0x7ff662e15e4b (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1485e4b) #7 0x7ff662e13981 (C:\Program Files\LLVM\bin\clang-tidy.exe+0x1483981) #8 0x7ff662e137cb (C:\Program Files\LLVM\bin\clang-tidy.exe+0x14837cb) #9 0x7ff662e270c0 (C:\Program Files\LLVM\bin\clang-ti
[llvm-bugs] [Bug 120152] [DirectX] Update DXContainerGlobals to get the shader flags from metadata rather than analysis
Issue 120152 Summary [DirectX] Update DXContainerGlobals to get the shader flags from metadata rather than analysis Labels backend:DirectX Assignees Reporter bogner DXContainerGlobals currently grabs shader flags from the analysis. This seems reasonable at a high level, but there are a couple of caveats: 1. We'd like to disallow running shader flags analysis after op lowering (See #120119), which means this would need to rely on the flags analysis being preserved since then 2. The flags are already embedded in DXIL metadata at this point, so we should just be able to copy them from there. We should update the pass to simply pull the flags in an opaque way from metadata and put them into the appropriate container part. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120155] read_unlocked doesn't support _IOLBF and _IONBF modes
Issue 120155 Summary read_unlocked doesn't support _IOLBF and _IONBF modes Labels libc Assignees michaelrj-google Reporter vonosmas `read_unlocked` currently only supports _IOFBF buffering, this bug is to track adding support for _IOLBF and _IONBF modes. (note - `write_unlocked` already does have support for them). See WIP patch in https://github.com/llvm/llvm-project/compare/main...braydonk:llvm-project:braydonk-file-buf-modes @michaelrj-google - LMK if this can be marked as "good-first-issue"? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120085] clang crash on x86_64-linux-gnu: Assertion `getType(Base)->isPointerType() || getType(Base)->isArrayType()' failed
Issue
120085
Summary
clang crash on x86_64-linux-gnu: Assertion `getType(Base)->isPointerType() || getType(Base)->isArrayType()' failed
Labels
clang
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/c1Y8cGv93
```console
:7:1: error: unknown type name 'uint32_t'
7 | uint32_t abcdef_h[(1 << 16) / sizeof(uint32_t)]
| ^
:7:38: error: use of undeclared identifier 'uint32_t'
7 | uint32_t abcdef_h[(1 << 16) / sizeof(uint32_t)]
| ^
:7:48: error: expected ';' after top level declarator
7 | uint32_t abcdef_h[(1 << 16) / sizeof(uint32_t)]
| ^
| ;
:12:16: warning: unknown attribute 'noipa' ignored [-Wunknown-attributes]
12 | __attribute__((noipa)) void sink (const void *p, ...) { (void)&p; }
|^
clang: /root/llvm-project/clang/lib/AST/ExprConstant.cpp:1747: void {anonymous}::LValue::addUnsizedArray({anonymous}::EvalInfo&, const clang::Expr*, clang::QualType): Assertion `getType(Base)->isPointerType() || getType(Base)->isArrayType()' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :31:3: current parser token 'zero'
2. :17:1: parsing function body 'main'
3. :17:1: in compound statement ('{}')
#0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8)
#1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04)
#2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x71f0ade42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x71f0ade969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x71f0ade42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x71f0ade287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x71f0ade2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x71f0ade39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x07723c02 (anonymous namespace)::LValue::addUnsizedArray((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::QualType) ExprConstant.cpp:0:0
#10 0x0779c152 (anonymous namespace)::PointerExprEvaluator::VisitCastExpr(clang::CastExpr const*) ExprConstant.cpp:0:0
#11 0x07750aeb clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#12 0x0779b768 (anonymous namespace)::PointerExprEvaluator::VisitCastExpr(clang::CastExpr const*) ExprConstant.cpp:0:0
#13 0x07750aeb clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#14 0x07752a2b EvaluatePointer(clang::Expr const*, (anonymous namespace)::LValue&, (anonymous namespace)::EvalInfo&, bool) ExprConstant.cpp:0:0
#15 0x0773ba5d Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#16 0x077584a6 EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) ExprConstant.cpp:0:0
#17 0x07758e8d EvaluateCallArg(clang::ParmVarDecl const*, clang::Expr const*, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, bool) ExprConstant.cpp:0:0
#18 0x077590b2 EvaluateArgs(llvm::ArrayRef, (anonymous namespace)::CallRef, (anonymous namespace)::EvalInfo&, clang::FunctionDecl const*, bool) ExprConstant.cpp:0:0
#19 0x07739154 (anonymous namespace)::VoidExprEvaluator::VisitCallExpr(clang::CallExpr const*) ExprConstant.cpp:0:0
#20 0x07739b65 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#21 0x0773c1c0 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#22 0x0773e53f (anonymous namespace)::DataRecursiveIntBinOpEvaluator::process((anonymous namespace)::DataRecursiveIntBinOpEvaluator::EvalResult&) ExprConstant.cpp:0:0
#23 0x077a04b3 (anonymous namespace)::IntExprEvaluator::VisitBinaryOperator(clang::BinaryOperator const*) ExprConstant.cpp:0:0
#24 0x0774d985 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#25 0x0773bc16 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#26 0x077444eb EvaluateAsRValue((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) ExprConstant.cpp:0:0
#27 0x07745c1c clang::Expr::EvaluateForOverflow(clang::
[llvm-bugs] [Bug 120082] clang crash on x86_64-linux-gnu: Assertion `Value > 0 && "Value must not be 0"' failed
Issue 120082 Summary clang crash on x86_64-linux-gnu: Assertion `Value > 0 && "Value must not be 0"' failed Labels clang Assignees Reporter bi6c Compiler Explorer: https://godbolt.org/z/9KqosxEdc ```console :3:47: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const volatile void *' [-Wint-conversion] 3 | _Static_assert (__atomic_always_lock_free (0, 1), ""); | ^ clang: /root/llvm-project/llvm/include/llvm/Support/Alignment.h:77: llvm::Align::Align(uint64_t): Assertion `Value > 0 && "Value must not be 0"' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics 1. parser at end of file #0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8) #1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04) #2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x7e8f0de42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7e8f0de969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x7e8f0de42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x7e8f0de287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x7e8f0de2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x7e8f0de39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x077a80cd (anonymous namespace)::IntExprEvaluator::VisitBuiltinCallExpr(clang::CallExpr const*, unsigned int) ExprConstant.cpp:0:0 #10 0x077a9322 (anonymous namespace)::IntExprEvaluator::VisitCallExpr(clang::CallExpr const*) ExprConstant.cpp:0:0 #11 0x0774c78e clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0 #12 0x0773bc16 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0 #13 0x077444eb EvaluateAsRValue((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) ExprConstant.cpp:0:0 #14 0x07747358 CheckEvalInICE(clang::Expr const*, clang::ASTContext const&) ExprConstant.cpp:0:0 #15 0x07748a2b CheckICE(clang::Expr const*, clang::ASTContext const&) ExprConstant.cpp:0:0 #16 0x077492df clang::Expr::isIntegerConstantExpr(clang::ASTContext const&, clang::SourceLocation*) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x77492df) #17 0x06adcbee clang::Sema::VerifyIntegerConstantExpression(clang::Expr*, llvm::APSInt*, clang::Sema::VerifyICEDiagnoser&, clang::Sema::AllowFoldKind) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6adcbee) #18 0x06add712 clang::Sema::VerifyIntegerConstantExpression(clang::Expr*, llvm::APSInt*, unsigned int, clang::Sema::AllowFoldKind) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6add712) #19 0x069fca24 clang::Sema::BuildStaticAssertDeclaration(clang::SourceLocation, clang::Expr*, clang::Expr*, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x69fca24) #20 0x06629d24 clang::Parser::ParseStaticAssertDeclaration(clang::SourceLocation&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6629d24) #21 0x06618009 clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, clang::SourceLocation*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6618009) #22 0x065d6e47 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x65d6e47) #23 0x065d7ccd clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, clang::Sema::ModuleImportState&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x65d7ccd) #24 0x065ca20a clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x65ca20a) #25 0x045e0668 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x45e0668) #26 0x04899a89 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4899a89) #27 0x0481c48e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x481c48e) #28 0x049862ce clang::Exec
[llvm-bugs] [Bug 120083] clang crash on x86_64-linux-gnu: clang::CodeGen::CodeGenFunction::EmitCallArgs()
Issue 120083 Summary clang crash on x86_64-linux-gnu: clang::CodeGen::CodeGenFunction::EmitCallArgs() Labels clang Assignees Reporter bi6c Compiler Explorer: https://godbolt.org/z/W4fK6d91f ```console clang: /root/llvm-project/clang/lib/CodeGen/CGCall.cpp:4545: void clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&, clang::CodeGen::CodeGenFunction::PrototypeWrapper, llvm::iterator_range >, clang::CodeGen::CodeGenFunction::AbstractCallee, unsigned int, clang::CodeGen::CodeGenFunction::EvaluationOrder): Assertion `(isGenericMethod || Ty->isVariablyModifiedType() || Ty.getNonReferenceType()->isObjCRetainableType() || getContext() .getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type mismatch in call argument!"' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics 1. parser at end of file 2. :6:1: LLVM IR generation of declaration 'sync_lock_test_and_set' 3. :6:1: Generating code for declaration 'sync_lock_test_and_set' #0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8) #1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04) #2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x79dab7c42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x79dab7c969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x79dab7c42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x79dab7c287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x79dab7c2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x79dab7c39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x043c69d9 clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&, clang::CodeGen::CodeGenFunction::PrototypeWrapper, llvm::iterator_range>, clang::CodeGen::CodeGenFunction::AbstractCallee, unsigned int, clang::CodeGen::CodeGenFunction::EvaluationOrder) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x43c69d9) #10 0x04461705 clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, clang::CodeGen::CGCallee const&, clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::Value*, llvm::CallBase**, clang::CodeGen::CGFunctionInfo const**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4461705) #11 0x044621a5 clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44621a5) #12 0x044b9ae4 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) CGExprScalar.cpp:0:0 #13 0x044ae16b clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0 #14 0x044b3dac clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44b3dac) #15 0x03fba1ac clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fba1ac) #16 0x03fc2646 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fc2646) #17 0x03fca024 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fca024) #18 0x04032ff4 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4032ff4) #19 0x04045d38 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4045d38) #20 0x040adb4a clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40adb4a) #21 0x040a8dd5 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40a8dd5) #22 0x040a91bb clang::CodeGen::CodeGenModule::EmitGlobal(clan
[llvm-bugs] [Bug 120084] clang crash on x86_64-linux-gnu: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
Issue
120084
Summary
clang crash on x86_64-linux-gnu: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
Labels
clang
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/4Prz7vEfW
```console
:3:2: error: expected ';' after union
3 | }long double __mutated_field__;
| ^
| ;
:1:1: warning: declaration does not declare anything [-Wmissing-declarations]
1 | union {
| ^
:4:2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
4 | a[] = { u"ff", [0].s[0] = u'x', [1] = u"\u1234\u4567", [1].s[0] = u'\u89ab' };
| ^
| int
:4:10: error: incompatible pointer to integer conversion initializing 'int' with an _expression_ of type 'unsigned short[3]' [-Wint-conversion]
4 | a[] = { u"ff", [0].s[0] = u'x', [1] = u"\u1234\u4567", [1].s[0] = u'\u89ab' };
| ^
clang: /root/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = clang::ConstantArrayType; From = const clang::ArrayType]: Assertion `isa(Val) && "cast() argument of incompatible type!"' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :4:79: current parser token ';'
#0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8)
#1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04)
#2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7489e0642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7489e06969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7489e0642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7489e06287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7489e062871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7489e0639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x06c8182f decltype(auto) llvm::cast(clang::ArrayType const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6c8182f)
#10 0x06ca858e (anonymous namespace)::InitListChecker::CheckDesignatedInitializer(clang::InitializedEntity const&, clang::InitListExpr*, clang::DesignatedInitExpr*, unsigned int, clang::QualType&, clang::DeclContext::specific_decl_iterator*, llvm::APSInt*, unsigned int&, clang::InitListExpr*, unsigned int&, bool, bool) SemaInit.cpp:0:0
#11 0x06cab020 (anonymous namespace)::InitListChecker::CheckArrayType(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, llvm::APSInt, bool, unsigned int&, clang::InitListExpr*, unsigned int&) SemaInit.cpp:0:0
#12 0x06ca4b59 (anonymous namespace)::InitListChecker::CheckListElementTypes(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, unsigned int&, clang::InitListExpr*, unsigned int&, bool) (.constprop.0) SemaInit.cpp:0:0
#13 0x06c9327a (anonymous namespace)::InitListChecker::CheckExplicitInitList(clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, clang::InitListExpr*, bool) (.constprop.0) SemaInit.cpp:0:0
#14 0x06c93c7e (anonymous namespace)::InitListChecker::InitListChecker(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*, clang::QualType&, bool, bool, bool, llvm::SmallVectorImpl*) SemaInit.cpp:0:0
#15 0x06c94005 diagnoseListInit(clang::Sema&, clang::InitializedEntity const&, clang::InitListExpr*) SemaInit.cpp:0:0
#16 0x06c9eeb4 clang::InitializationSequence::Diagnose(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::ArrayRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6c9eeb4)
#17 0x06c945b5 clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, clang::QualType*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6c945b5)
#18 0x069675d9 clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x69675d9)
#19 0x0660005a clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6
[llvm-bugs] [Bug 120086] clang crash on x86_64-linux-gnu: clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType)
Issue
120086
Summary
clang crash on x86_64-linux-gnu: clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType)
Labels
clang
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/Y9aPsbM16
```console
:59:5: warning: incompatible redeclaration of library function 'printf' [-Wincompatible-library-redeclaration]
59 | int printf(char fmt, ...);
| ^
:59:5: note: 'printf' is a builtin with type 'int (const char *, ...)'
:63:3: error: incompatible pointer to integer conversion passing 'char[3]' to parameter of type 'char' [-Wint-conversion]
63 | __builtin_dump_struct(a, printf);
| ^
:63:3: note: in call to printing function with arguments '("%s", "struct A")' while dumping struct
:59:17: note: passing argument to parameter 'fmt' here
59 | int printf(char fmt, ...);
| ^
:63:3: error: cannot compile this scalar _expression_ yet
63 | __builtin_dump_struct(a, printf);
| ^~~~
Unexpected placeholder builtin type!
UNREACHABLE executed at /root/llvm-project/clang/lib/CodeGen/CodeGenTypes.cpp:581!
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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. parser at end of file
2. :61:6: LLVM IR generation of declaration 'test'
3. :61:6: Generating code for declaration 'test'
#0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8)
#1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04)
#2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7ee5e2842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7ee5e28969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7ee5e2842476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7ee5e28287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x03bad9ca (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3bad9ca)
#8 0x040ff71b clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40ff71b)
#9 0x044982ce (anonymous namespace)::ScalarExprEmitter::VisitExpr(clang::Expr*) (.isra.0) CGExprScalar.cpp:0:0
#10 0x044ae113 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#11 0x044b00eb (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#12 0x044b705b (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) CGExprScalar.cpp:0:0
#13 0x044ae4d1 clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#14 0x044b3dac clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44b3dac)
#15 0x0443c7fe clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x443c7fe)
#16 0x044606d5 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44606d5)
#17 0x03fc23b5 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fc23b5)
#18 0x03fca024 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fca024)
#19 0x04032ff4 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4032ff4)
#20 0x04045d38 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4045d38)
#21 0x040adb4a clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40adb4a)
#22 0x040a8dd5 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40a8dd5)
#23 0x040a91bb clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compi
[llvm-bugs] [Bug 120076] [SLPVectorizer] Miscompile at O3
Issue
120076
Summary
[SLPVectorizer] Miscompile at O3
Labels
miscompilation,
llvm:SLPVectorizer
Assignees
Reporter
dtcxzyw
Reproducer: https://alive2.llvm.org/ce/z/_88AAB
```
; bin/opt -passes=slp-vectorizer reduced.ll -S
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"
define i8 @func_129() {
entry:
%conv4.i.i = zext i16 0 to i32
%conv7.i.i = sext i16 0 to i32
%cmp8.i.i = icmp slt i32 %conv7.i.i, %conv4.i.i
%conv9.i.i = zext i1 %cmp8.i.i to i32
%or10.i.i = or i32 %conv9.i.i, %conv4.i.i
%cmp11.i.i = icmp eq i32 %or10.i.i, %conv4.i.i
%sub.i.i79.peel.i = sub i16 0, 1
%xor5.i81.peel.i = zext i16 %sub.i.i79.peel.i to i32
%conv7.i84.peel.i = sext i16 0 to i32
%cmp8.i85.peel.i = icmp slt i32 %conv7.i84.peel.i, %xor5.i81.peel.i
%conv9.i86.peel.i = zext i1 %cmp8.i85.peel.i to i32
%or10.i87.peel.i = or i32 %conv9.i86.peel.i, %xor5.i81.peel.i
%cmp11.i88.peel.i = icmp eq i32 %or10.i87.peel.i, %xor5.i81.peel.i
%conv13.i89.peel.i = zext i1 %cmp8.i85.peel.i to i8
ret i8 %conv13.i89.peel.i
}
```
```
define i8 @func_129() {
entry:
%sub.i.i79.peel.i = sub i16 0, 1
%0 = insertelement <2 x i16> , i16 %sub.i.i79.peel.i, i32 0
%1 = icmp slt <2 x i16> zeroinitializer, %0
%2 = zext <2 x i1> %1 to <2 x i16>
%3 = or <2 x i16> %2, %0
%4 = icmp eq <2 x i16> %3, %0
%5 = extractelement <2 x i1> %1, i32 0
%conv13.i89.peel.i = zext i1 %5 to i8
ret i8 %conv13.i89.peel.i
}
```
```
define i8 @src() {
entry:
%sub.i.i79.peel.i = sub i16 0, 1
%xor5.i81.peel.i = zext i16 %sub.i.i79.peel.i to i32
%conv7.i84.peel.i = sext i16 0 to i32
%cmp8.i85.peel.i = icmp slt i32 %conv7.i84.peel.i, %xor5.i81.peel.i
%conv13.i89.peel.i = zext i1 %cmp8.i85.peel.i to i8
ret i8 %conv13.i89.peel.i
}
=>
define i8 @tgt() {
entry:
%sub.i.i79.peel.i = sub i16 0, 1
%#0 = insertelement <2 x i16> { poison, 0 }, i16 %sub.i.i79.peel.i, i32 0
%#1 = icmp slt <2 x i16> { 0, 0 }, %#0
%#5 = extractelement <2 x i1> %#1, i32 0
%conv13.i89.peel.i = zext i1 %#5 to i8
ret i8 %conv13.i89.peel.i
}
Transformation doesn't verify!
ERROR: Value mismatch
Example:
Source:
i16 %sub.i.i79.peel.i = #x (65535, -1)
i32 %xor5.i81.peel.i = #x (65535)
i32 %conv7.i84.peel.i = #x (0)
i1 %cmp8.i85.peel.i = #x1 (1)
i8 %conv13.i89.peel.i = #x01 (1)
Target:
i16 %sub.i.i79.peel.i = #x (65535, -1)
<2 x i16> %#0 = < #x (65535, -1), #x (0) >
<2 x i1> %#1 = < #x0 (0), #x0 (0) >
i1 %#5 = #x0 (0)
i8 %conv13.i89.peel.i = #x00 (0)
Source value: #x01 (1)
Target value: #x00 (0)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120078] [SPIR-V] SPIRVGlobalRegistry::createOpType() doesn't ensure that iterator and machine basic block of the insertion point are consistent
Issue 120078 Summary [SPIR-V] SPIRVGlobalRegistry::createOpType() doesn't ensure that iterator and machine basic block of the insertion point are consistent Labels new issue Assignees VyacheslavLevytskyy Reporter VyacheslavLevytskyy One of SYCL CTS cases (group_barrier) fails to build due to inconsistency between iterator and machine basic block of the insertion point inside of SPIRVGlobalRegistry::createOpType(). The result is ``` llc: /localdisk2/vlevytsk/llvm-project/llvm/include/llvm/CodeGen/MachineBasicBlock.h:1020: llvm::MachineBasicBlock::iterator llvm::MachineBasicBlock::insert(iterator, llvm::MachineInstr*): Assertion `(I == end() || I->getParent() == this) && "iterator points outside of basic block"' failed. ``` Triaging shows that while SPIRVGlobalRegistry::createOpType() itself expects that users of this function are to insert definitions at the insertion point set by this utility function (that is always the first MBB), it might happen that the instruction gets relocated along its way through passes. This means that there is no guarantee for SPIRVGlobalRegistry::createOpType() to create a valid insertion point without additional checks before using one of previously stored positions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120093] Assertion `VT.isInteger() && "Cannot create FP integer constant!"' failed.
Issue
120093
Summary
Assertion `VT.isInteger() && "Cannot create FP integer constant!"' failed.
Labels
new issue
Assignees
Reporter
TatyanaDoubts
To reproduce run the following test on llc:
```
; ModuleID = 'reduced.ll'
source_filename = "reduced.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-ni:1-p2:32:8:8:32-ni:2"
target triple = "x86_64-unknown-linux-gnu"
define double @widget() gc "statepoint-example" {
bb:
%insertelement = insertelement <2 x double> , double 0.00e+00, i64 0
%fcmp = fcmp uge <2 x double> zeroinitializer, %insertelement
%extractelement = extractelement <2 x i1> %fcmp, i64 0
%extractelement1 = extractelement <2 x i1> %fcmp, i64 1
%select = select i1 %extractelement, i1 %extractelement1, i1 false
br i1 %select, label %bb2, label %bb3
bb2: ; preds = %bb
ret double 0.00e+00
bb3: ; preds = %bb
unreachable
}
```
Reproducer: https://godbolt.org/z/EG69jzzfz
Stack dump:
```
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel
1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@widget'
#0 0x03c7e2e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3c7e2e8)
#1 0x03c7bcec SignalHandler(int) Signals.cpp:0:0
#2 0x7c08a0642520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#3 0x7c08a06969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#4 0x7c08a0642476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#5 0x7c08a06287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#6 0x7c08a062871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#7 0x7c08a0639e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#8 0x039f7f6b llvm::SelectionDAG::getConstant(llvm::ConstantInt const&, llvm::SDLoc const&, llvm::EVT, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x39f7f6b)
#9 0x039f8c00 llvm::SelectionDAG::getAllOnesConstant(llvm::SDLoc const&, llvm::EVT, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x39f8c00)
#10 0x038b1b31 (anonymous namespace)::DAGCombiner::visitFREEZE(llvm::SDNode*) (.isra.0) DAGCombiner.cpp:0:0
#11 0x038ca30f (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*) DAGCombiner.cpp:0:0
#12 0x038cca3c (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) DAGCombiner.cpp:0:0
#13 0x038ce328 (anonymous namespace)::DAGCombiner::Run(llvm::CombineLevel) DAGCombiner.cpp:0:0
#14 0x038d0c3b llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOptLevel) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x38d0c3b)
#15 0x03a32a08 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a32a08)
#16 0x03a366f9 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a366f9)
#17 0x03a379b0 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a379b0)
#18 0x03a283af llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x3a283af)
#19 0x02bc1829 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#20 0x031c737f llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31c737f)
#21 0x031c7731 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31c7731)
#22 0x031c7fd1 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x31c7fd1)
#23 0x0089a608 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#24 0x0078563e main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x78563e)
#25 0x7c08a0629d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#26 0x7c08a0629e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#27 0x00890f35 _start (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x890f35)
Program terminated with signal: SIGSEGV
Compiler returned: 139
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120080] clang crash on x86_64-linux-gnu: Assertion `E->isPRValue() && E->getType()->hasPointerRepresentation()' failed.
Issue
120080
Summary
clang crash on x86_64-linux-gnu: Assertion `E->isPRValue() && E->getType()->hasPointerRepresentation()' failed.
Labels
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/Po5sjedv9
```console
:4:33: error: incompatible integer to pointer conversion passing 'char' to parameter of type 'const void *' [-Wint-conversion]
4 | c = __builtin_assume_aligned (c, 16);
| ^
:4:5: error: incompatible pointer to integer conversion assigning to 'char' from 'void *' [-Wint-conversion]
4 | c = __builtin_assume_aligned (c, 16);
| ^
clang: /root/llvm-project/clang/lib/AST/ExprConstant.cpp:9436: bool EvaluatePointer(const clang::Expr*, {anonymous}::LValue&, {anonymous}::EvalInfo&, bool): Assertion `E->isPRValue() && E->getType()->hasPointerRepresentation()' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. :5:3: current parser token 'c'
2. :3:1: parsing function body 'foo'
3. :3:1: in compound statement ('{}')
#0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8)
#1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04)
#2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7341f2442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7341f24969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7341f2442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7341f24287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7341f242871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7341f2439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x077529fa EvaluatePointer(clang::Expr const*, (anonymous namespace)::LValue&, (anonymous namespace)::EvalInfo&, bool) ExprConstant.cpp:0:0
#10 0x0779d095 (anonymous namespace)::PointerExprEvaluator::VisitBuiltinCallExpr(clang::CallExpr const*, unsigned int) ExprConstant.cpp:0:0
#11 0x0779e8e2 (anonymous namespace)::PointerExprEvaluator::VisitCallExpr(clang::CallExpr const*) ExprConstant.cpp:0:0
#12 0x077509f2 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#13 0x07752a2b EvaluatePointer(clang::Expr const*, (anonymous namespace)::LValue&, (anonymous namespace)::EvalInfo&, bool) ExprConstant.cpp:0:0
#14 0x07785360 (anonymous namespace)::IntExprEvaluator::VisitCastExpr(clang::CastExpr const*) ExprConstant.cpp:0:0
#15 0x0774c885 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#16 0x0773bc16 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#17 0x0773e53f (anonymous namespace)::DataRecursiveIntBinOpEvaluator::process((anonymous namespace)::DataRecursiveIntBinOpEvaluator::EvalResult&) ExprConstant.cpp:0:0
#18 0x077a04b3 (anonymous namespace)::IntExprEvaluator::VisitBinaryOperator(clang::BinaryOperator const*) ExprConstant.cpp:0:0
#19 0x0774d9c5 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#20 0x0773bc16 Evaluate(clang::APValue&, (anonymous namespace)::EvalInfo&, clang::Expr const*) ExprConstant.cpp:0:0
#21 0x077444eb EvaluateAsRValue((anonymous namespace)::EvalInfo&, clang::Expr const*, clang::APValue&) ExprConstant.cpp:0:0
#22 0x07745c1c clang::Expr::EvaluateForOverflow(clang::ASTContext const&) const (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x7745c1c)
#23 0x06803644 clang::Sema::CheckForIntOverflow(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6803644)
#24 0x068337ad clang::Sema::CheckCompletedExpr(clang::Expr*, clang::SourceLocation, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x68337ad)
#25 0x06bcda3c clang::Sema::ActOnFinishFullExpr(clang::Expr*, clang::SourceLocation, bool, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6bcda3c)
#26 0x06ede90e clang::Sema::ActOnExprStmt(clang::ActionResult, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x6ede90e)
#27 0x066cf2b4 clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x66cf2b4)
#28 0x066c55ae clang::Parser::P
[llvm-bugs] [Bug 120081] clang crash on x86_64-linux-gnu: Assertion `isa(CanonicalType)' failed
Issue 120081 Summary clang crash on x86_64-linux-gnu: Assertion `isa(CanonicalType)' failed Labels clang Assignees Reporter bi6c Compiler Explorer: https://godbolt.org/z/qdx3o195o ```console :14:19: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'volatile void *' [-Wint-conversion] 14 | __atomic_clear (__ATOMIC_RELEASE, __ATOMIC_RELEASE); | ^~~~ :14:26: note: expanded from macro '__ATOMIC_RELEASE' 14 | #define __ATOMIC_RELEASE 3 | ^ clang: /root/llvm-project/clang/include/clang/AST/Type.h:8805: const T* clang::Type::castAs() const [with T = clang::PointerType]: Assertion `isa(CanonicalType)' 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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics 1. :18:1: current parser token 'int' 2. :8:1: LLVM IR generation of declaration 'tf' 3. :8:1: Generating code for declaration 'tf' #0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8) #1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04) #2 0x03ba2068 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x78d6c8442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x78d6c84969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x78d6c8442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x78d6c84287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x78d6c842871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x78d6c8439e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x041e3763 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x41e3763) #10 0x0437ec6a clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::GlobalDecl, unsigned int, clang::CallExpr const*, clang::CodeGen::ReturnValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x437ec6a) #11 0x0446222e clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*, clang::CodeGen::ReturnValueSlot, llvm::CallBase**) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x446222e) #12 0x044b9ae4 (anonymous namespace)::ScalarExprEmitter::VisitCallExpr(clang::CallExpr const*) CGExprScalar.cpp:0:0 #13 0x044ae16b clang::StmtVisitorBase::Visit(clang::Stmt*) CGExprScalar.cpp:0:0 #14 0x044b3dac clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44b3dac) #15 0x0443c7fe clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, clang::CodeGen::AggValueSlot, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x443c7fe) #16 0x044606d5 clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x44606d5) #17 0x03fc23b5 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fc23b5) #18 0x03fca024 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3fca024) #19 0x04032ff4 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4032ff4) #20 0x04045d38 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4045d38) #21 0x040adb4a clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40adb4a) #22 0x040a8dd5 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40a8dd5) #23 0x040a91bb clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x40a91bb) #24 0x040b3983 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0 #25 0x045e2b06 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0 #26 0x000
[llvm-bugs] [Bug 120071] [llvm-cov] lcov-export generates invalid lcov files
Issue
120071
Summary
[llvm-cov] lcov-export generates invalid lcov files
Labels
new issue
Assignees
Reporter
zgtm
In certain cases, `llvm-cov export` exports lcov files, that seem to be invalid. They contain coverage information for the line after the final newline character.
For these lcov files, `genhtml` (part of the lcov project) will report the following error:
```
genhtml: ERROR: (range) /some/path/supp.h contains only 2 lines but coverage data refers to line 3
```
## Reproduce
`main.c`:
```C
#define FOO();
void foobar() {
#include "supp.h"
}
int main(){}
```
`supp.h`:
```C
#define BAR FOO
BAR()
```
Run
```sh
clang -o main -fcoverage-mapping -fprofile-instr-generate main.c
LLVM_PROFILE_FILE='main.profraw' ./main
llvm-profdata merge -sparse -o main.profdata main.profraw
llvm-cov export -format=lcov -instr-profile="" main > main.lcov
```
## Expected Behaviour
`main.lcov` does not contain
```
DA:3,0
```
For `supp.h`.
## Actual Behaviour
`main.lcov` contains
```
SF:/some/path/supp.h
…
DA:3,0
```
However, there is no line 3 in `supp.h`.
`genhtml main.lcov` will report "genhtml: ERROR: (range) /some/path/supp.h contains only 2 lines but coverage data refers to line 3"
## Additional Information
```
$ clang --version
Ubuntu clang version 19.1.1 (1ubuntu1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin
```
```
$ llvm-profdata --version
Ubuntu LLVM version 19.1.1
Optimized build.
```
```
$ llvm-cov --version
Ubuntu LLVM version 19.1.1
Optimized build.
```
On Kubuntu 24.10.a
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120088] clang crash on x86_64-linux-gnu: error in backend: Broken module found, compilation aborted!
Issue
120088
Summary
clang crash on x86_64-linux-gnu: error in backend: Broken module found, compilation aborted!
Labels
Assignees
Reporter
bi6c
Compiler Explorer: https://godbolt.org/z/zMP936sGe
```console
:55:5: warning: function 'async_mutual_loop2' declared 'noreturn' should not return [-Winvalid-noreturn]
55 | return async_leaf1(ctx);
| ^
:57:5: warning: function 'async_mutual_loop2' declared 'noreturn' should not return [-Winvalid-noreturn]
57 | return async_leaf2(ctx);
| ^
:59:3: warning: function 'async_mutual_loop2' declared 'noreturn' should not return [-Winvalid-noreturn]
59 | return async_mutual_loop1(u - 2, ctx);
| ^
:69:22: warning: unknown attribute 'noipa' ignored [-Wunknown-attributes]
69 | char __attribute__ ((noipa)) c_calling_async(MYBOOL b, unsigned u) {
| ^
musttail call must precede a ret with an optional bitcast
musttail call swifttailcc void @async_mutual_loop2(i32 noundef %sub, ptr noundef swiftasync %7) #2, !dbg !105
fatal error: error in backend: Broken module found, compilation aborted!
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 -fno-verbose-asm -c --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics
1. parser at end of file
2. Optimizer
3. Running pass "verify" on module ""
#0 0x03c56df8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c56df8)
#1 0x03c54b04 llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c54b04)
#2 0x03ba25d6 llvm::CrashRecoveryContext::HandleExit(int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3ba25d6)
#3 0x03c4be2e llvm::sys::Process::Exit(int, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3c4be2e)
#4 0x00cdf720 LLVMErrorHandler(void*, char const*, bool) cc1_main.cpp:0:0
#5 0x03bad683 llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3bad683)
#6 0x03bad7e8 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3bad7e8)
#7 0x03636bb8 (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3636bb8)
#8 0x03ef736e llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3ef736e)
#9 0x036018c0 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x36018c0)
#10 0x03f0a1ef (anonymous namespace)::EmitAssemblyHelper::RunOptimizationPipeline(clang::BackendAction, std::unique_ptr>&, std::unique_ptr>&, clang::BackendConsumer*) BackendUtil.cpp:0:0
#11 0x03f0dd65 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>, clang::BackendConsumer*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3f0dd65)
#12 0x045e028e clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x45e028e)
#13 0x065ca42c clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x65ca42c)
#14 0x045e0668 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x45e0668)
#15 0x04899a89 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x4899a89)
#16 0x0481c48e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x481c48e)
#17 0x049862ce clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x49862ce)
#18 0x00ce1c7f cc1_main(llvm::ArrayRef, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0xce1c7f)
#19 0x00cd971a ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0
#20 0x04624ad9 void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#21 0x03ba2514 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+0x3ba2514)
#22 0x0
[llvm-bugs] [Bug 120089] [ConstraintElim] `icmp spred x, y` implies `icmp samesign upred x, y`
Issue
120089
Summary
[ConstraintElim] `icmp spred x, y` implies `icmp samesign upred x, y`
Labels
missed-optimization,
llvm:transforms
Assignees
dtcxzyw
Reporter
dtcxzyw
Alive2: https://alive2.llvm.org/ce/z/ZNNbj_
```
define i1 @src(i32 %x, i32 %y) {
entry:
%cond = icmp sgt i32 %x, %y
br i1 %cond, label %if.then, label %if.else
if.then:
%cmp = icmp samesign ugt i32 %x, %y
ret i1 %cmp
if.else:
ret i1 false
}
define i1 @tgt(i32 %x, i32 %y) {
entry:
%cond = icmp sgt i32 %x, %y
br i1 %cond, label %if.then, label %if.else
if.then:
ret i1 true
if.else:
ret i1 false
}
```
We already perform similar optimizations in https://github.com/llvm/llvm-project/pull/115893.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120092] [[Clang]] Don't traverse parameter list twice in `RequiresExpr`.
Issue 120092 Summary [[Clang]] Don't traverse parameter list twice in `RequiresExpr`. Labels clang Assignees Reporter 16bit-ykiko https://github.com/llvm/llvm-project/blob/3c3094b60d3587b1db8ef35b3bf54e73ac5894d9/clang/include/clang/AST/RecursiveASTVisitor.h#L2985-L2991 Currently, ASTVisitor traverses parameter list twice in `RequiresExpr`. First, and then it is when traverse `decls` of the body of `RequiresExpr`, another is when traversing `S->getLocalParameters()`. This is unnecessary and could be optimized. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120066] Error executing --convert-memref-to-emitc
Issue 120066 Summary Error executing --convert-memref-to-emitc Labels new issue Assignees Reporter pyl3000 When I run `mlir-opt test.mlir --convert-memref-to-emitc -o out.mlir` I get the following error:  ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120119] [DirectX] Run shader flags analysis before DXILOpLowering
Issue 120119 Summary [DirectX] Run shader flags analysis before DXILOpLowering Labels new issue Assignees Reporter bogner We should run shader flags analysis before DXILOpLowering, so that it can work with DirectX target intrinsics rather than having to recover information from the lowered operations. This will significantly simplify tasks like #118140 and #114557. Note that this will mean very late passes (ie, DXContainerGlobals) shouldn't rely on shader flags analysis directly, since it won't be possible to re-run it if it's invalid at that point. To do: - Move the translate metadata pass after the dxil op lowering pass - Update DXContainerGlobals to get the shader flags from metadata rather than analysis - Add asserts if flag analysis is run post lowering ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120111] Python LLDB API does not expose a way to get type CV-information
Issue 120111 Summary Python LLDB API does not expose a way to get type CV-information Labels new issue Assignees Reporter droptopx The python API for LLDB does not seem to provide a way to get const-volatile information for `SBType`'s. This might also be an issue for the C++ API, I didn't check. Something like `SBType.is_const` and `SBType.is_volatile` could be added, or even `SBType.GetQualifiers()` and then the qualifiers would be flags in an enum so any subset of them could be checked through one API call. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120112] [LLDB] Python API does not expose a way to query the VLA-ness of an array
Issue 120112 Summary [LLDB] Python API does not expose a way to query the VLA-ness of an array Labels Assignees Reporter droptopx The python API for LLDB does not seem to provide a way to query whether or not an array SBType is a VLA. This might also be an issue for the C++ API, I didn't check. `SBType.GetByteSize()` actually calculates as if there is at least 1 element in the array, so checking for 0 doesn't work. Also `type[]` and `type[0]` are distinct types (in C) so it wouldn't quite work in either case. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120124] [RISCV64] can not compile LLVM-IR code with opt -O1 or -O2
Issue 120124 Summary [RISCV64] can not compile LLVM-IR code with opt -O1 or -O2 Labels new issue Assignees Reporter tankf33der ``` $ uname -m riscv64 $ cd $ git clone https://github.com/picolisp/pil21.git $ cd pil21/src $ opt -O1 -o ht.bc ht.ll $ llc ht.bc -relocation-model=pic -o ht.s $ clang ht.s -o ../lib/ht.so -shared /usr/lib/gcc/riscv64-alpine-linux-musl/14.2.0/../../../../riscv64-alpine-linux-musl/bin/ld: /tmp/ht-edd1ab.o(.text+0x66a): 6 bytes required for alignment to 8-byte boundary, but only 4 present /usr/lib/gcc/riscv64-alpine-linux-musl/14.2.0/../../../../riscv64-alpine-linux-musl/bin/ld: can't relax section: bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) $ ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120129] Optimization in clang frontend breaks `dynamic_cast` on Apple platforms.
Issue
120129
Summary
Optimization in clang frontend breaks `dynamic_cast` on Apple platforms.
Labels
clang
Assignees
Reporter
ahatanak
This is caused by 9d525bf94b255df89587db955b5fa2d3c03c2c3e.
`dynamic_cast` in the following code fails unless the optimization is disabled by passing `-fno-assume-unique-vtables`.
% cat a.h
```
struct Foo {
virtual ~Foo();
};
struct Bar final : public Foo {
};
Foo* makeBar();
```
% cat a.cc
```
#include "a.h"
Foo::~Foo() {}
Foo* makeBar() {
return new Bar();
}
```
% cat b.cc
```
#include "a.h"
int main() {
Foo* f = makeBar();
Bar* b = dynamic_cast(f); // b will incorrectly be nullptr
return !!b;
}
```
% clang++ -std=c++11 -c a.cc -O1
% clang++ -std=c++11 -c b.cc -O1
% clang++ -shared -o liba.so a.o
% clang++ --std=c++11 -o a.out b.o -Wl,-rpath,$PWD liba.so
% ./a.out
% echo $?
0
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120131] [amdgpu] Generic scoped fences are miscompiled
Issue 120131 Summary [amdgpu] Generic scoped fences are miscompiled Labels backend:AMDGPU Assignees arsenm, JonChesterfield, b-sumner, jhuber6, dhruvachak Reporter JonChesterfield Joseph wrote https://github.com/llvm/llvm-project/pull/119619 to replace uses of the amdgpu specific fence builtin with __scoped_atomic_thread_fence. That should have been fine (the amdgpu specific __builtin_amdgcn_fence only exists because it predates the generic one), except amdgpu mangles the scope as shown in https://github.com/llvm/llvm-project/pull/120095. This _might_ be correct behaviour on opencl. I'd rather it was __opencl_atomic_thread_fence if the language wants that sort of logic, but either way, it definitely caused runtime failures on openmp after 119619 landed. I don't think that default makes sense on openmp or hip (but I could be wrong, I don't fully understand the openmp spec and https://rocm.docs.amd.com/projects/HIP/en/latest/reference/cpp_language_extensions.html doesn't mention it). The "fix" to remove the special casing in 120095 is opposed on the basis that it's probably wrong on opencl (and it'll make things slower even when it's right) which I think means we need to revert 119619 while we work out what to do here. This issue is created to document the current dynamic (as best understood by someone who wrote neither of those pull requests) and to see if we can reach consensus to revert 119619, as it's using a generic clang intrinsic which doesn't work properly, until such point as we can agree to fix the clang intrinsic or otherwise make things work properly. I.e. I don't think we can leave openmp's runtime with extra race conditions. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120181] LLVM Xcode6.1 compile crash
Issue 120181 Summary LLVM Xcode6.1 compile crash Labels new issue Assignees Reporter a20251313 On mac use swift-project compile: Steps: step 1. git clone https://github.com/apple/swift.git swift cd swift utils/update-checkout --tag swift-6.0.2-RELEASE --clone step 2. utils/build-script --xcode --debug --skip-build-benchmarks --swift-darwin-supported-archs "$(uname -m)" --sccache --skip-ios --skip-tvos --skip-watchos --libswift=off step3 use xcode6.1 compile then error occurs PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /Users/ranjingfu/Desktop/swift-project/build/Xcode-DebugAssert/llvm-macosx-x86_64/Debug/bin/llvm-tblgen -gen-instr-info -instr-info-expand-mi-operand-info=0 -I /Users/ranjingfu/Desktop/swift-project/llvm-project/llvm/lib/Target/X86 -I/Users/ranjingfu/Desktop/swift-project/build/Xcode-DebugAssert/llvm-macosx-x86_64/include -I/Users/ranjingfu/Desktop/swift-project/llvm-project/llvm/include -I /Users/ranjingfu/Desktop/swift-project/llvm-project/llvm/lib/Target /Users/ranjingfu/Desktop/swift-project/llvm-project/llvm/lib/Target/X86/X86.td --write-if-changed -o /Users/ranjingfu/Desktop/swift-project/build/Xcode-DebugAssert/llvm-macosx-x86_64/lib/Target/X86/X86GenInstrInfo.inc 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 llvm-tblgen 0x000100622b4d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 61 1 llvm-tblgen 0x0001006230bb PrintStackTraceSignalHandler(void*) + 27 2 llvm-tblgen 0x000100620d46 llvm::sys::RunSignalHandlers() + 134 3 llvm-tblgen 0x000100623a7f SignalHandler(int) + 223 4 libsystem_platform.dylib 0x7ff808ec2e9d _sigtramp + 29 5 llvm-tblgen 0x0001007a426f 6 libsystem_c.dylib 0x7ff808daeb19 abort + 126 7 llvm-tblgen 0x0001001fcea2 void std::__1::__check_strict_weak_ordering_sorted[abi:dn180100]*, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0>(std::__1::pair*, std::__1::pair*, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0&) + 610 8 llvm-tblgen 0x0001001fcb9d void std::__1::__sort_impl[abi:dn180100]*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0>(std::__1::__wrap_iter*>, std::__1::__wrap_iter*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0&) + 157 9 llvm-tblgen 0x0001001fcaf9 void std::__1::sort[abi:dn180100]*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0>(std::__1::__wrap_iter*>, std::__1::__wrap_iter*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0) + 57 10 llvm-tblgen 0x0001001fca4d void llvm::sort*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0>(std::__1::__wrap_iter*>, std::__1::__wrap_iter*>, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0) + 77 11 llvm-tblgen 0x0001001f91f3 void llvm::sort, std::__1::allocator>>&, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0>(std::__1::vector, std::__1::allocator>>&, processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&)::$_0) + 83 12 llvm-tblgen 0x0001001ed3ae processSTIPredicate(llvm::STIPredicateFunction&, llvm::DenseMap, llvm::detail::DenseMapPair> const&) + 2558 13 llvm-tblgen 0x0001001eb96a llvm::CodeGenSchedModels::collectSTIPredicates() + 634 14 llvm-tblgen 0x0001001e6514 llvm::CodeGenSchedModels::CodeGenSchedModels(llvm::RecordKeeper&, llvm::CodeGenTarget const&) + 644 15 llvm-tblgen 0x0001001ebf95 llvm::CodeGenSchedModels::CodeGenSchedModels(llvm::RecordKeeper&, llvm::CodeGenTarget const&) + 37 16 llvm-tblgen 0x00010022cf3d std::__1::__unique_if::__unique_single std::__1::make_unique[abi:dn180100](llvm::RecordKeeper&, llvm::CodeGenTarget const&) + 61 17 llvm-tblgen 0x00010022ce98 llvm::CodeGenTarget::getSchedModels() const + 56 18 llvm-tblgen 0x00010042dcf9 (anonymous namespace)::InstrInfoEmitter::InstrInfoEmitter(llvm::RecordKeeper&) + 121 19 llvm-tblgen 0x00010042c47d (anonymous namespace)::InstrInfoEmitter::InstrInfoEmitter(llvm::RecordKeeper&) + 29 20 llvm-tblgen 0x00010042c3c5 Emi
[llvm-bugs] [Bug 120169] [TargetTransformUtils][VectorUtils] Update `isTriviallyVectorizable` to accept target intrinsics
Issue 120169 Summary [TargetTransformUtils][VectorUtils] Update `isTriviallyVectorizable` to accept target intrinsics Labels new issue Assignees Reporter inbelic As part of [previous work](https://github.com/llvm/llvm-project/issues/117030), we want to consolidate the usage of the `is[Trivially|VectorIntrinsic]...` functions in `VectorUtils.h`. The remaining work is to let `isTriviallyVectorizable` allow target-specific intrinsics denote if they are trivially vectorizable. The difficulty in this issue is to justify when we should pass a `nullptr` into the updated function calls, as there are a number of functions (`getVectorIntrinsicIDForCall`, `isNotCrossLaneOpartion`, etc.) that use the function. AC: - [ ] Implement `isTargetIntrinsicTriviallyVectorizable` in `TargetTransformInfo.[h|cpp]` and `BasicTTIImpl.h` - [ ] Update `isTriviallyVectorizable` to accept a `TargetTransformInfo` parameter and invoke `isTargetIntrinsicTriviallyVectorizable` - [ ] Update all use-cases of `isTriviallyVectorizable` to provide a TTI or a motivated reason to provide `nullptr` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120175] clangd crash: crash backtrace
Issue 120175 Summary clangd crash: crash backtrace Labels new issue Assignees Reporter LuoZhongYao "PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace." " #0 0x7f92ae417b7a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib64/libLLVM.so.19.1+0x217b7a)" " #1 0x7f92ae414b24 llvm::sys::RunSignalHandlers() (/lib64/libLLVM.so.19.1+0x214b24)" " #2 0x7f92ae4182eb (/lib64/libLLVM.so.19.1+0x2182eb)" " #3 0x7f92adc25dd0 __restore_rt (/lib64/libc.so.6+0x19dd0)" " #4 0x55583a581fa0 (/usr/bin/clangd+0x4d9fa0)" " #5 0x55583a554c73 (/usr/bin/clangd+0x4acc73)" " #6 0x55583a55baee (/usr/bin/clangd+0x4b3aee)" " #7 0x55583a24b1e4 (/usr/bin/clangd+0x1a31e4)" " #8 0x55583a44a157 (/usr/bin/clangd+0x3a2157)" " #9 0x55583a4498cd (/usr/bin/clangd+0x3a18cd)" "#10 0x55583a4453a5 (/usr/bin/clangd+0x39d3a5)" "#11 0x55583a44352f (/usr/bin/clangd+0x39b52f)" "#12 0x55583a5bd692 (/usr/bin/clangd+0x515692)" "#13 0x7f92adc7ccd7 start_thread (/lib64/libc.so.6+0x70cd7)" "#14 0x7f92add00c8c __GI___clone3 (/lib64/libc.so.6+0xf4c8c)" "Signalled during AST worker action: Build AST" ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120174] [param][optimized]loop optimization
Issue 120174 Summary [param][optimized]loop optimization Labels new issue Assignees Reporter zhaojiangkun-1 I want to test the `--param max-unroll-times` parameter, and it doesn't seem to work. Does the command not take effect after the `O2` option is enabled? No related document is found. Please explain how this command takes effect. test code： https://godbolt.org/z/3Ec44vefc ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120186] [Mlir][affine] --lower-affine crashes in AffineToStandard.cpp:46: buildMinMaxReductionSeq
Issue
120186
Summary
[Mlir][affine] --lower-affine crashes in AffineToStandard.cpp:46: buildMinMaxReductionSeq
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: ff939b06a5
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir --lower-affine`
a.mlir:
```
module {
llvm.mlir.global private constant @__constant_1x31x28xi32_5(dense<4939> : tensor<1x31x28xi32>) {addr_space = 0 : i32, alignment = 64 : i64} : !llvm.array<1 x array<31 x array<28 x i32>>>
func.func private @func2(%arg0: memref<1x31x28xi32, strided<[?, ?, ?], offset: ?>>, %arg1: memref<1x31x28xi32, strided<[?, ?, ?], offset: ?>>) -> () {
%3 = llvm.mlir.addressof @__constant_1x31x28xi32_5 : !llvm.ptr
%8 = llvm.mlir.constant(0 : index) : i64
%9 = llvm.mlir.undef : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%10 = llvm.mlir.constant(3735928559 : index) : i64
%13 = llvm.mlir.constant(1 : index) : i64
%14 = llvm.mlir.constant(31 : index) : i64
%15 = llvm.mlir.constant(28 : index) : i64
%16 = llvm.mlir.constant(868 : index) : i64
%80 = llvm.getelementptr %3[0, 0, 0, 0] : (!llvm.ptr) -> !llvm.ptr, !llvm.array<1 x array<31 x array<28 x i32>>>
%81 = llvm.inttoptr %10 : i64 to !llvm.ptr
%82 = llvm.insertvalue %81, %9[0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%83 = llvm.insertvalue %80, %82[1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%84 = llvm.insertvalue %8, %83[2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%85 = llvm.insertvalue %13, %84[3, 0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%86 = llvm.insertvalue %14, %85[3, 1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%87 = llvm.insertvalue %15, %86[3, 2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%88 = llvm.insertvalue %16, %87[4, 0] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%89 = llvm.insertvalue %15, %88[4, 1] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%90 = llvm.insertvalue %13, %89[4, 2] : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)>
%92 = builtin.unrealized_conversion_cast %90 : !llvm.struct<(ptr, ptr, i64, array<3 x i64>, array<3 x i64>)> to memref<1x31x28xi32>
%alloc = memref.alloc() : memref<31x28xi32>
%alloc_95 = memref.alloc() : memref<1x31x28xi32>
affine.parallel (%arg2) = (max()) to (min()) {
affine.parallel (%arg3) = (0) to (31) {
affine.parallel (%arg4) = (0) to (28) {
%249 = affine.load %92[%arg2, %arg3, %arg4] : memref<1x31x28xi32>
affine.store %249, %alloc_95[%arg2, %arg3, %arg4] : memref<1x31x28xi32>
}
}
}
return
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-release/llvm-project/mlir/lib/Conversion/AffineToStandard/AffineToStandard.cpp:46: Value buildMinMaxReductionSeq(Location, arith::CmpIPredicate, ValueRange, OpBuilder &): Assertion `!values.empty() && "empty min/max chain"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt a.mlir --lower-affine
#0 0x563768152348 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111f348)
#1 0x56376814fe5e llvm::sys::RunSignalHandlers() (/data/szy/MLIR/llvm-release/llvm-project/build/bin/mlir-opt+0x111ce5e)
#2 0x563768152cdd SignalHandler(int) Signals.cpp:0:0
#3 0x7fef4939f420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7fef489dc00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x7fef489bb859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#6 0x7fef489bb729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#7 0x7fef489bb729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#8 0x7fef489ccfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#9 0x56376aa91164 buildMinMaxReductionSeq(mlir::Location, mlir::arith::CmpIPredicate, mlir::ValueRange, mlir::OpBuilder&) AffineToStandard.cpp:0:0
#10 0x56376aa9371b (anonymous namespace)::AffineParallelLowering::matchAndRewrite(mlir::affine::AffineParallelOp, mlir::PatternRewriter&) const AffineToStandard.cpp:0:0
#11 0x56376e123591 void llvm::function_ref::callback_fn, llvm::function_ref, llvm::function_ref)::$_0>(long) PatternApplicator.cpp:0:0
#12 0x56376e12025b mlir::PatternApplicator::matchAndRewrite(mlir::Operation*, mlir::PatternRewriter&, llvm::function_ref, llvm:
[llvm-bugs] [Bug 120189] [Mlir][affine] --affine-loop-fusion="fusion-compute-tolerance=0" crashes in Utils.cpp:293: mlir::presburger::mergeLocalVars
Issue
120189
Summary
[Mlir][affine] --affine-loop-fusion="fusion-compute-tolerance=0" crashes in Utils.cpp:293: mlir::presburger::mergeLocalVars
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: b3d2548d5b04
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir --affine-loop-fusion="fusion-compute-tolerance=0"`
a.mlir:
```
#map = affine_map<()[s0, s1] -> (s0 * 23 + s1)>
module {
func.func @func1(%arg0: memref<1x23x26xi32, strided<[?, ?, ?], offset: ?>>) -> () {
%cst = arith.constant 63.9809875 : f32
%cst_0 = arith.constant 1.19825836E-6 : f32
%cst_1 = arith.constant 1.18534706E-4 : f32
%cst_2 = arith.constant 0.00226843474 : f32
%cst_3 = arith.constant 0.00489352504 : f32
%cst_4 = arith.constant -2.76076837E-16 : f32
%cst_5 = arith.constant 2.00018794E-13 : f32
%cst_6 = arith.constant -8.60467184E-11 : f32
%cst_7 = arith.constant 5.12229725E-8 : f32
%cst_8 = arith.constant 1.48572235E-5 : f32
%cst_9 = arith.constant 6.37261954E-4 : f32
%cst_10 = arith.constant 0.00489352457 : f32
%cst_11 = arith.constant 7.99881172 : f32
%cst_12 = arith.constant 0.00e+00 : f32
%alloc = memref.alloc() {alignment = 64 : i64} : memref<23x26xf32>
affine.for %arg1 = 0 to 23 {
affine.for %arg2 = 0 to 26 {
%0 = math.fma %cst, %cst_4, %cst_5 : f32
%1 = math.fma %cst, %0, %cst_6 : f32
%2 = math.fma %cst, %1, %cst_7 : f32
%3 = math.fma %cst, %2, %cst_8 : f32
%4 = math.fma %cst, %3, %cst_9 : f32
%5 = math.fma %cst, %4, %cst_10 : f32
%6 = arith.mulf %5, %cst_11 : f32
%7 = math.fma %cst, %cst_0, %cst_1 : f32
%8 = math.fma %cst, %7, %cst_2 : f32
%9 = math.fma %cst, %8, %cst_3 : f32
%10 = arith.divf %6, %9 : f32
affine.store %10, %alloc[%arg1, %arg2] : memref<23x26xf32>
}
}
%alloc_13 = memref.alloc() {alignment = 64 : i64} : memref<1x26xf32>
affine.for %arg1 = 0 to 1 {
affine.for %arg2 = 0 to 23 {
affine.for %arg3 = 0 to 26 {
%0 = affine.apply #map()[%arg1, %arg2]
%1 = affine.load %alloc[%0, %arg3] : memref<23x26xf32>
%2 = affine.load %alloc_13[%arg1, %arg3] : memref<1x26xf32>
%3 = arith.addf %1, %2 : f32
affine.store %3, %alloc_13[%arg1, %arg3] : memref<1x26xf32>
}
}
}
return
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Analysis/Presburger/Utils.cpp:293: void mlir::presburger::mergeLocalVars(IntegerRelation &, IntegerRelation &, llvm::function_ref): Assertion `relA.getSpace().isCompatible(relB.getSpace()) && "Spaces should be compatible."' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir --affine-loop-fusion=fusion-compute-tolerance=0
#0 0x563e79ba6919 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:11
#1 0x563e79ba6dcb PrintStackTraceSignalHandler(void*) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x563e79ba4fff llvm::sys::RunSignalHandlers() /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Signals.cpp:105:5
#3 0x563e79ba749e SignalHandler(int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x7ff5ee152420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#5 0x7ff5ed78f00b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7ff5ed76e859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#7 0x7ff5ed76e729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x7ff5ed76e729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x7ff5ed77ffd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#10 0x563e83959bdb mlir::presburger::mergeLocalVars(mlir::presburger::IntegerRelation&, mlir::presburger::IntegerRelation&, llvm::function_ref) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Analysis/Presburger/Utils.cpp:298:25
#11 0x563e838bbf77 mlir::presburger::IntegerRelation::mergeLocalVars(mlir::presburger::IntegerRelation&) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Analysis/Presburger/IntegerRelation.cpp:1384:10
#12 0x563e7ea6fc50 mlir::affine::MemRefAccess::getAccessRelation(mlir::presburger::IntegerRelation&) const /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Affine/Analysis/AffineAnalysis.cpp:497:3
#13 0x563e7ea6edca mlir::affine::checkMemrefAccessDependence(mlir::affine::MemRefAccess const&, mlir::affi
[llvm-bugs] [Bug 120190] [Flang] Incorrect result of FORALL when nested functions are used for the mask
Issue 120190 Summary [Flang] Incorrect result of FORALL when nested functions are used for the mask Labels regression, flang Assignees jeanPerier Reporter kawashima-fj @jeanPerier #118070 has one more regression. Source program: ```fortran program main implicit none type ty1 integer :: cmp end type ty1 integer :: arr(4) integer :: i do i = 1, 4 arr(i) = i end do forall (i=1:4, bar(foo(i)) == 3) arr(i - 2) = arr(i) end forall do i = 1, 4 print *, arr(i) end do contains pure function foo(dmy) implicit none integer, intent(in)::dmy type(ty1) :: foo(2) foo%cmp = dmy end function pure function bar(dmy) implicit none type(ty1), intent(in):: dmy(2) integer :: bar bar = dmy(1)%cmp end function end program ``` Run (on AArch64): ```console $ flang test.f90 $ ./a.out 1 2 3 4 ``` The statement in `FORALL` shoud be executed only for `i == 3` and it should output: ```console 3 2 3 4 ``` Curiously, this happens only with `-O0`. Tested with the latest Flang/LLVM `main` branch (commit 8d550aa0f027eb2cf32850f3905dc1db22317587). This is detected by [Fujitsu Compiler Test Suite run on Linaro CI](https://linaro.atlassian.net/browse/LLVM-1459). The soruce program above is a simplified version of [Fujitsu/Fortran/0608/Fujitsu-Fortran-0608_0218.test](https://github.com/fujitsu/compiler-test-suite/blob/main/Fortran/0608/0608_0218.f90). Your #119219 fixed #118922 but did not fixed this issue. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120191] Affine dialect to EmitC dialect
Issue 120191 Summary Affine dialect to EmitC dialect Labels new issue Assignees Reporter pyl3000 Using the mlir-opt tool, how do I go from the Affine dialect (.mlir) and lower it to the EmitC dialect (.mlir)? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120192] Global symbols are not unique when using lld
Issue
120192
Summary
Global symbols are not unique when using lld
Labels
lld,
BOLT
Assignees
Reporter
linsinan1995
It looks like LLD will drop the versioning suffix and leave global symbols with the same names in executables, which prevents BOLT from optimizing the binary. It is an expected output from LLD, and is there any option we could use to keep '@VER' strings?
Here is an example (simplified from [libnuma](https://github.com/numactl/numactl)):
test.c
```
#define SYMVER(a,b) __asm__ (".symver " a "," b);
static int nodemask_sz = 0;
SYMVER("numa_max_possible_node_v1", "numa_max_possible_node@libnuma_1.1")
int
numa_max_possible_node_v1(void)
{
return ((sizeof(unsigned long long)*8)-1);
}
SYMVER("numa_max_possible_node_v2", "numa_max_possible_node@@libnuma_1.2")
int
numa_max_possible_node_v2(void)
{
return nodemask_sz;
}
```
main.c
```
int
numa_max_possible_node(void);
int main() {
return numa_max_possible_node();
}
```
## 1. build with clang + ld
clang test.c main.c -Wl,-q -o a.ld.out
llvm-bolt a.ld.out -o a.opt
BOLT works fine, and the symbol table:
```
00401110 l F .text 000b numa_max_possible_node@libnuma_1.1
00401120 g F .text 000d numa_max_possible_node@@libnuma_1.2
00401120 g F .text 000d numa_max_possible_node_v2
00401110 g F .text 000b numa_max_possible_node_v1
```
## 2. build with clang + lld
clang test.c main.c -fuse-ld=lld -Wl,-q -o a.lld.out
llvm-bolt a.lld.out -o a.opt
BOLT throws an error: `BOLT-ERROR: bad input binary, global symbol "numa_max_possible_node" is not unique`, and the symbol table looks like
```
002016a0 g F .text 000b numa_max_possible_node_v1
002016b0 g F .text 000d numa_max_possible_node_v2
002016a0 g F .text 000b numa_max_possible_node
002016b0 g F .text 000d numa_max_possible_node
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120193] [Mlir] -sccp crashes in BuiltinAttributes.cpp:966: mlir::DenseElementsAttr::get
Issue
120193
Summary
[Mlir] -sccp crashes in BuiltinAttributes.cpp:966: mlir::DenseElementsAttr::get
Labels
mlir
Assignees
Reporter
Emilyaxe
git version: b3d2548d5b04
system: `Ubuntu 18.04.6 LTS`
reproduce with: `/data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir -sccp`
a.mlir:
```
module {
llvm.func @main() {
%5 = llvm.mlir.constant(0 : index) : i64
llvm.br ^bb21(%5 : i64)
^bb21(%150: i64):
llvm.br ^bb22
^bb22:
%153 = vector.broadcast %150 : i64 to vector<128xi64>
llvm.return
}
}
```
stack trace:
```
mlir-opt: /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/IR/BuiltinAttributes.cpp:966: static DenseElementsAttr mlir::DenseElementsAttr::get(ShapedType, ArrayRef): Assertion `intAttr.getType() == eltType && "expected integer attribute type to equal element type"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /data/szy/MLIR/llvm-debug/llvm-project/build/bin/mlir-opt a.mlir -sccp
#0 0x561258825919 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:11
#1 0x561258825dcb PrintStackTraceSignalHandler(void*) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#2 0x561258823fff llvm::sys::RunSignalHandlers() /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Signals.cpp:105:5
#3 0x56125882649e SignalHandler(int) /data/szy/MLIR/llvm-debug/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
#4 0x7fa08f0c4420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#5 0x7fa08e70100b raise /build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x7fa08e6e0859 abort /build/glibc-LcI20x/glibc-2.31/stdlib/abort.c:81:7
#7 0x7fa08e6e0729 get_sysdep_segment_value /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x7fa08e6e0729 _nl_load_domain /build/glibc-LcI20x/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x7fa08e6f1fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#10 0x56125d96b665 mlir::DenseElementsAttr::get(mlir::ShapedType, llvm::ArrayRef) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/IR/BuiltinAttributes.cpp:967:24
#11 0x56125cac4784 mlir::vector::BroadcastOp::fold(mlir::vector::BroadcastOpGenericAdaptor>) /data/szy/MLIR/llvm-debug/llvm-project/mlir/lib/Dialect/Vector/IR/VectorOps.cpp:2527:12
#12 0x56125cb90e1a llvm::LogicalResult mlir::Op::Impl, mlir::OpTrait::ZeroSuccessors, mlir::OpTrait::OneOperand, mlir::OpTrait::OpInvariants, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::AlwaysSpeculatableImplTrait, mlir::MemoryEffectOpInterface::Trait, mlir::InferIntRangeInterface::Trait>::foldSingleResultHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) /data/szy/MLIR/llvm-debug/llvm-project/mlir/include/mlir/IR/OpDefinition.h:1907:38
#13 0x56125cb90d71 mlir::Op::Impl, mlir::OpTrait::ZeroSuccessors, mlir::OpTrait::OneOperand, mlir::OpTrait::OpInvariants, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::AlwaysSpeculatableImplTrait, mlir::MemoryEffectOpInterface::Trait, mlir::InferIntRangeInterface::Trait>::getFoldHookFn()::'lambda'(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&)::operator()(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const /data/szy/MLIR/llvm-debug/llvm-project/mlir/include/mlir/IR/OpDefinition.h:1883:16
#14 0x56125cb90d1d llvm::LogicalResult llvm::detail::UniqueFunctionBase, llvm::SmallVectorImpl&>::CallImpl::Impl, mlir::OpTrait::ZeroSuccessors, mlir::OpTrait::OneOperand, mlir::OpTrait::OpInvariants, mlir::ConditionallySpeculatable::Trait, mlir::OpTrait::AlwaysSpeculatableImplTrait, mlir::MemoryEffectOpInterface::Trait, mlir::InferIntRangeInterface::Trait>::getFoldHookFn()::'lambda'(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const>(void*, mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) /data/szy/MLIR/llvm-debug/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:222:12
#15 0x5612589a6b2f llvm::unique_function, llvm::SmallVectorImpl&) const>::operator()(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const /data/szy/MLIR/llvm-debug/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:413:12
#16 0x56125cb900fe mlir::RegisteredOperationName::Model::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) /data/szy/MLIR/llvm-debug/llvm-project/mlir/include/mlir/IR/OperationSupport.h:538:14
#17 0x56125dae0e2e mlir::OperationName::foldHook(mlir::Operation*, llvm::ArrayRef, llvm::SmallVectorImpl&) const /data/szy/MLIR/llvm-debug/llvm-project/mlir/include/mlir/IR/OperationSupport.h:265:23
#18 0x56125dad9888 mlir::Operation::fo
[llvm-bugs] [Bug 120168] opt dot-cfg pass print wrong dbg number or I misuse this pass?
Issue
120168
Summary
opt dot-cfg pass print wrong dbg number or I misuse this pass?
Labels
new issue
Assignees
Reporter
tomgu1991
Hi, all, I use the following command to print cfg of llvm IR, but got the wrong dbg! number.
```cpp
//
// Created
//
void foo();
void bar();
void test1(int x) { foo(); }
void test2(int x) { bar(); }
```
```shell
clang -S -g -emit-llvm -Xclang -disable-O0-optnone -fno-discard-value-names test.cpp -o test.ll
opt -passes='dot-cfg' test.ll -S -o test_opt.ll
```
In the test_opt.ll(the same as test.ll) test1 is correct, as follows
But, in the test_opt.ll, test2 is the following: !dbg! is from 21 to 23
```
; Function Attrs: mustprogress noinline uwtable
define dso_local void @_Z5test2i(i32 noundef %x) #0 !dbg !19 {
entry:
%x.addr = alloca i32, align 4
store i32 %x, ptr %x.addr, align 4
call void @llvm.dbg.declare(metadata ptr %x.addr, metadata !20, metadata !DIExpression()), !dbg !21
call void @_Z3barv(), !dbg !22
ret void, !dbg !23
}
!16 = !DILocation(line: 8, column: 16, scope: !10)
!17 = !DILocation(line: 8, column: 21, scope: !10)
!18 = !DILocation(line: 8, column: 28, scope: !10)
!19 = distinct !DISubprogram(name: "test2", linkageName: "_Z5test2i", scope: !1, file: !1, line: 10, type: !11, scopeLine: 10, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !14)
!20 = !DILocalVariable(name: "x", arg: 1, scope: !19, file: !1, line: 10, type: !13)
!21 = !DILocation(line: 10, column: 16, scope: !19)
!22 = !DILocation(line: 10, column: 21, scope: !19)
!23 = !DILocation(line: 10, column: 28, scope: !19)
```
However, the dbg in dot is from 16 to 18,
So, is it a bug in opt dot-cfg pass or I misuse this?
Thanks!
zuxing
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120167] [Clang] Matrix types are currently not supported in constant evaluation
Issue
120167
Summary
[Clang] Matrix types are currently not supported in constant evaluation
Labels
clang:frontend,
constexpr
Assignees
Reporter
Sirraide
We support vector types, so supporting matrices as well would make sense, even though it sounds like it’d be quite a bit of work as it would probably involve adding a new `APValue` kind.
As an example, this (https://godbolt.org/z/WE84hhYvP):
```c++
template
constexpr bool f() {
T t = T();
return true;
}
using M = int [[clang::matrix_type(4, 4)]];
static_assert(f());
```
doesn’t work currently:
```console
:9:15: error: static assertion _expression_ is not an integral constant _expression_
9 | static_assert(f());
| ^~
:3:11: note: non-literal type 'int __attribute__((matrix_type(4, 4)))' cannot be used in a constant _expression_
3 | T t = T();
| ^
:9:15: note: in call to 'f()'
9 | static_assert(f());
| ^~
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 120178] `ios_base::sync_with_stdio` doesn't seem to do anything
Issue
120178
Summary
`ios_base::sync_with_stdio` doesn't seem to do anything
Labels
bug,
libc++
Assignees
Reporter
cjdb
Here's the implementation for `ios_base::sync_with_stdio`:
```cpp
bool ios_base::sync_with_stdio(bool sync) {
static bool previous_state = true;
bool r = previous_state;
previous_state = sync;
return r;
}
```
As far as I can tell, that's only shuffling the state of a local bool, which tells me that it might not be decoupling iostream from stdio (I can't find any usage of the function to probe the state by the library, and since it's a local variable, it's not affecting anything on a broader level).
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
