[llvm-bugs] [Bug 85349] Unresolved TPOFF64 in -static-pie when using lld
Issue
85349
Summary
Unresolved TPOFF64 in -static-pie when using lld
Labels
lld
Assignees
Reporter
wc00862805aj
Here is the `demo.go` file that I compiled:
```go
package main
// #cgo LDFLAGS: -ldl
// #include
// #include
import "C"
import (
"fmt"
)
func main() {
fmt.Printf("This is a Go demo.\n")
C.CString("libsystemd-login.so.0")
return
}
```
When I compile it with the following command:
```shell
export CC=
go build -buildmode=pie -o demo-ld.exe -ldflags '-buildid=none -tmpdir=. -extldflags=-ftrapv -extldflags=-Wl,-z,relro,-z,now -linkmode=external -extldflags=-static-pie' demo.go;
```
`demo-ld` can be executed correctly. However, if I compile it with:
```shell
export CC=clang
go build -buildmode=pie -o demo-lld.exe -ldflags '-buildid=none -tmpdir=. -extldflags=-ftrapv -extldflags=-Wl,-z,relro,-z,now -linkmode=external -extldflags=-static-pie' demo.go;
```
`demo-lld` cannot be executed and ends with a "Segmentation fault (core dumped)" error.
Hence, I tried to use `readelf -r` on these files to identify the cause of the failure. I discovered that `demo-lld.exe` cannot resolve the TPOFF64 relocation type statically, while `demo-ld.exe` can. As a result, `demo-lld.exe` has several TPOFF64 entries in its dynamic relocation section. I also attempted to debug `demo-lld` with GDB and found that when the linker skips the resolution of TPOFF64, it can be executed correctly. However, if the resolution is performed, it fails at `dl_allocate_static_tls` due to uninitialized TLS, which does not occur with `demo-ld.exe`.
During my search on glibc, I came across an existing issue report (https://sourceware.org/bugzilla/show_bug.cgi?id=31302) that addresses this problem. According to their conclusion, `lld` should be able to resolve TPOFF64 relocations with -static-pie.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85343] [18 regression] Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed
Issue
85343
Summary
[18 regression] Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed
Labels
new issue
Assignees
Reporter
berolinux
```
$ clang++ -c test.cc
test.cc:16:32: warning: _expression_ result unused [-Wunused-value]
16 | template d(f) { e::ba; }
| ^~~
test.cc:19:20: note: in instantiation of function template specialization 'd::d' requested here
19 | d b = [=](auto) { [this] {}; };
|^
clang++: /builddir/build/BUILD/llvm-project-18.1.1.src/clang/include/clang/AST/Type.h:753: const ExtQualsTypeCommonBase *clang::QualType::getCommonPtr() const: Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' 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: clang++ -c test.cc
1. parser at end of file
2. test.cc:16:25: instantiating function definition 'd::d'
3. test.cc:13:15: instantiating function definition 'e::ba'
4. test.cc:8:39: instantiating function definition 'ao'
5. test.cc:4:30: instantiating class definition 'ac'
6. test.cc:19:20: instantiating function definition 'a::(anonymous class)::operator()'
#0 0x7f6d59d9a576 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib64/libLLVM.so.18.1+0x459a576)
#1 0x7f6d59d991ea llvm::sys::RunSignalHandlers() (/usr/lib64/libLLVM.so.18.1+0x45991ea)
#2 0x7f6d59cb0dce (/usr/lib64/libLLVM.so.18.1+0x44b0dce)
#3 0x7f6d55253690 (/usr/lib64/libc.so.6+0x3f690)
#4 0x7f6d552a2edc (/usr/lib64/libc.so.6+0x8eedc)
#5 0x7f6d552535e2 raise (/usr/lib64/libc.so.6+0x3f5e2)
#6 0x7f6d5523c4ad abort (/usr/lib64/libc.so.6+0x284ad)
#7 0x7f6d5523c3d5 (/usr/lib64/libc.so.6+0x283d5)
#8 0x7f6d5524c052 (/usr/lib64/libc.so.6+0x38052)
#9 0x7f6d61cf03b4 clang::InitializationSequence::InitializeFrom(clang::Sema&, clang::InitializedEntity const&, clang::InitializationKind const&, llvm::MutableArrayRef, bool, bool) (/usr/lib64/libclang-cpp.so.18.1+0x28f03b4)
#10 0x7f6d61d22dd7 clang::Sema::BuildCaptureInit(clang::sema::Capture const&, clang::SourceLocation, bool) (/usr/lib64/libclang-cpp.so.18.1+0x2922dd7)
#11 0x7f6d61d2360d clang::Sema::BuildLambdaExpr(clang::SourceLocation, clang::SourceLocation, clang::sema::LambdaScopeInfo*) (/usr/lib64/libclang-cpp.so.18.1+0x292360d)
#12 0x7f6d620b4e5c (/usr/lib64/libclang-cpp.so.18.1+0x2cb4e5c)
#13 0x7f6d62084eae (/usr/lib64/libclang-cpp.so.18.1+0x2c84eae)
#14 0x7f6d620916b9 (/usr/lib64/libclang-cpp.so.18.1+0x2c916b9)
#15 0x7f6d6209a7ed (/usr/lib64/libclang-cpp.so.18.1+0x2c9a7ed)
#16 0x7f6d620c00b6 clang::Sema::SubstStmt(clang::Stmt*, clang::MultiLevelTemplateArgumentList const&) (/usr/lib64/libclang-cpp.so.18.1+0x2cc00b6)
#17 0x7f6d620cf659 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool, bool) (/usr/lib64/libclang-cpp.so.18.1+0x2ccf659)
#18 0x7f6d62014ace clang::Sema::DeduceReturnType(clang::FunctionDecl*, clang::SourceLocation, bool) (/usr/lib64/libclang-cpp.so.18.1+0x2c14ace)
#19 0x7f6d61ac741a clang::Sema::DiagnoseUseOfDecl(clang::NamedDecl*, llvm::ArrayRef, clang::ObjCInterfaceDecl const*, bool, bool, clang::ObjCInterfaceDecl*, bool) (/usr/lib64/libclang-cpp.so.18.1+0x26c741a)
#20 0x7f6d61e9a977 (/usr/lib64/libclang-cpp.so.18.1+0x2a9a977)
#21 0x7f6d61eb5f2e clang::Sema::BuildCallToObjectOfClassType(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation) (/usr/lib64/libclang-cpp.so.18.1+0x2ab5f2e)
#22 0x7f6d61b1754a clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, bool, bool) (/usr/lib64/libclang-cpp.so.18.1+0x271754a)
#23 0x7f6d61b7606f clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*) (/usr/lib64/libclang-cpp.so.18.1+0x277606f)
#24 0x7f6d62088525 (/usr/lib64/libclang-cpp.so.18.1+0x2c88525)
#25 0x7f6d62074008 (/usr/lib64/libclang-cpp.so.18.1+0x2c74008)
#26 0x7f6d62071521 (/usr/lib64/libclang-cpp.so.18.1+0x2c71521)
#27 0x7f6d6209f942 (/usr/lib64/libclang-cpp.so.18.1+0x2c9f942)
#28 0x7f6d6209dca5 (/usr/lib64/libclang-cpp.so.18.1+0x2c9dca5)
#29 0x7f6d6207aa2d (/usr/lib64/libclang-cpp.so.18.1+0x2c7aa2d)
#30 0x7f6d62076ca0 (/usr/lib64/libclang-cpp.so.18.1+0x2c76ca0)
#31 0x7f6d62071521 (/usr/lib64/libclang-cpp.so.18.1+0x2c71521)
#32 0x7f6d620d4984 clang::TemplateDeclInstantiator::VisitVarTemplateSpecializationDecl(clang::VarTemplateDecl*, clang::VarDecl*, clang::TemplateArg
[llvm-bugs] [Bug 85337] Define a generic macro for -mno-unaligned-access
Issue 85337 Summary Define a generic macro for -mno-unaligned-access Labels new issue Assignees Reporter wzssyqa Arm32/Arm64/LoongArch/MIPSr6 may disable unaligned memory access with option `-mno-unaligned-access` Currently Arm32/Arm64 predefine `__ARM_FEATURE_UNALIGNED`, while LoongArch and MIPSr6 not yet. Maybe it's time for use to define a more generic predefined macro for this case. Will `__UNALIGN_ACCESS_DISABLED__` be OK? For GCC, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85335] Conflicting declaration error with `__using_if_exists__` in libc++
Issue
85335
Summary
Conflicting declaration error with `__using_if_exists__` in libc++
Labels
libc++,
embedded
Assignees
Reporter
petrhosek
When trying to use libc++ with LLVM libc on a baremetal platform, we encountered an issue with the `__using_if_exists__` attribute which was introduced in https://reviews.llvm.org/D90188:
```
In file included from /llvm_libcxx/include/algorithm:1973:
/llvm_libcxx/include/__algorithm/remove.h:28:1: error: declaration conflicts with target of using declaration already in scope
28 | remove(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value) {
| ^
/llvm_libcxx/include/cstdio:155:1: note: target of using declaration
155 | using ::remove _LIBCPP_USING_IF_EXISTS;
| ^
/llvm_libcxx/include/cstdio:155:9: note: using declaration
155 | using ::remove _LIBCPP_USING_IF_EXISTS;
| ^
```
This is because baremetal version of the `stdio.h` libc header doesn't include `remove` (since there's no filesystem support).
A more minimal example of this issue is:
```cpp
void foo();
namespace N {
void bar();
using ::foo __attribute__((__using_if_exists__));
using ::bar __attribute__((__using_if_exists__));
}
void baz() {
N::bar();
}
```
This results in the following error (you can also see it at https://godbolt.org/z/dTxqnc1oP):
```
:7:11: error: target of using declaration conflicts with declaration already in scope
7 | using ::bar __attribute__((__using_if_exists__));
| ^
:7:3: note: target of using declaration
7 | using ::bar __attribute__((__using_if_exists__));
| ^
:4:8: note: conflicting declaration
4 | void bar();
|^
1 error generated.
Compiler returned: 1
```
Normally, `remove` is declared in `stdio.h`, which corresponds to the `foo` case.
In our case, there's no `remove` symbol in `stdio.h` and as such there's no such symbol in the global namespace, but there's `remove` in the `std::` namespace introduced by `algorithm` corresponding to the `bar` case.
Is this an issue with the `__using_if_exists__` implementation or intended behavior?
This is related to issue https://github.com/llvm/llvm-project/issues/84879.
CC @ldionne @zygoloid @AaronBallman @epilk
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85334] Missing exception handling codegen for copy constructor of vector even with -fexceptions
Issue
85334
Summary
Missing exception handling codegen for copy constructor of vector even with -fexceptions
Labels
question,
libc++
Assignees
Reporter
hiraditya
There is no exception handling for if/when `operator new` fails? gcc generates exception handling code. I'm curious if this is the intended behavior?
Repro: https://godbolt.org/z/hc5PEffK8
```cpp
#include
#include
std::vector td() {
int arr[]{-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15,-5, 10, 15 -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,-5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10, 15, -5, 10,};
auto b = std::ranges::begin(arr);
auto e = std::ranges::end(arr);
std::vector dd(b, e);
return dd;
}
```
$ clang++ -O3 -std=c++23 -stdlib=libc++ -g0 -fexceptions
```
td(): # @td()
pushr14
pushrbx
pushrax
mov rbx, rdi
xorps xmm0, xmm0
movups xmmword ptr [rdi], xmm0
mov qword ptr [rdi + 16], 0
mov edi, 444
calloperator new(unsigned long)@PLT
mov qword ptr [rbx], rax
lea r14, [rax + 444]
mov qword ptr [rbx + 16], r14
lea rsi, [rip + .L__const.td().arr]
mov edx, 444
mov rdi, rax
callmemcpy@PLT
mov qword ptr [rbx + 8], r14
mov rax, rbx
add rsp, 8
pop rbx
pop r14
ret
.L__const.td().arr:
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 10 # 0xa
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
.long 15 # 0xf
.long 4294967291 # 0xfffb
.long 10 # 0xa
[llvm-bugs] [Bug 85333] GVNSink prodices incorrect codegen with respect to GEPs
Issue
85333
Summary
GVNSink prodices incorrect codegen with respect to GEPs
Labels
bug,
miscompilation,
llvm:GVN
Assignees
Reporter
PiJoules
```
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7em-none-unknown-eabi"
%"struct.std::pair" = type <{ i32, %struct.substruct, [2 x i8] }>
%struct.substruct = type { i8, i8 }
%"struct.std::random_access_iterator_tag" = type { i8 }
define linkonce_odr dso_local void @__advance(ptr noundef nonnull align 4 dereferenceable(4) %__i, i32 noundef %__n) local_unnamed_addr {
entry:
%0 = call i1 @llvm.is.constant.i32(i32 %__n)
%cmp = icmp eq i32 %__n, 1
%or.cond = and i1 %0, %cmp
br i1 %or.cond, label %if.then, label %if.else
if.then: ; preds = %entry
%1 = load ptr, ptr %__i, align 4
%incdec.ptr = getelementptr inbounds i8, ptr %1, i32 8
store ptr %incdec.ptr, ptr %__i, align 4
br label %if.end6
if.else: ; preds = %entry
%2 = call i1 @llvm.is.constant.i32(i32 %__n)
%cmp2 = icmp eq i32 %__n, -1
%or.cond7 = and i1 %2, %cmp2
br i1 %or.cond7, label %if.then3, label %if.else5
if.then3: ; preds = %if.else
%3 = load ptr, ptr %__i, align 4
%incdec.ptr4 = getelementptr inbounds i8, ptr %3, i32 -8
store ptr %incdec.ptr4, ptr %__i, align 4
br label %if.end6
if.else5: ; preds = %if.else
%4 = load ptr, ptr %__i, align 4
%add.ptr = getelementptr inbounds %"struct.std::pair", ptr %4, i32 %__n
store ptr %add.ptr, ptr %__i, align 4
br label %if.end6
if.end6: ; preds = %if.then3, %if.else5, %if.then
ret void
}
```
The above IR when piped through gvn-sink via `./bin/opt < /tmp/repro.ll -passes=gvn-sink -S` produces:
```
; ModuleID = ''
source_filename = ""
target datalayout = "e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64"
target triple = "thumbv7em-none-unknown-eabi"
define linkonce_odr dso_local void @__advance(ptr noundef nonnull align 4 dereferenceable(4) %__i, i32 noundef %__n) local_unnamed_addr {
entry:
%0 = call i1 @llvm.is.constant.i32(i32 %__n)
%cmp = icmp eq i32 %__n, 1
%or.cond = and i1 %0, %cmp
br i1 %or.cond, label %if.then, label %if.else
if.then: ; preds = %entry
br label %if.end6
if.else: ; preds = %entry
%1 = call i1 @llvm.is.constant.i32(i32 %__n)
%cmp2 = icmp eq i32 %__n, -1
%or.cond7 = and i1 %1, %cmp2
br i1 %or.cond7, label %if.then3, label %if.else5
if.then3: ; preds = %if.else
br label %if.end6
if.else5: ; preds = %if.else
br label %if.end6
if.end6: ; preds = %if.else5, %if.then3, %if.then
%.sink1 = phi i32 [ 8, %if.then ], [ -8, %if.then3 ], [ %__n, %if.else5 ]
%2 = load ptr, ptr %__i, align 4
%incdec.ptr = getelementptr inbounds i8, ptr %2, i32 %.sink1
store ptr %incdec.ptr, ptr %__i, align 4
ret void
}
; Function Attrs: convergent nocallback nofree nosync nounwind willreturn memory(none)
declare i1 @llvm.is.constant.i32(i32) #0
attributes #0 = { convergent nocallback nofree nosync nounwind willreturn memory(none) }
```
The GEP in the result is incorrect. Prior, the GEPs were
```
%incdec.ptr = getelementptr inbounds i8, ptr %1, i32 8
%incdec.ptr4 = getelementptr inbounds i8, ptr %3, i32 -8
%add.ptr = getelementptr inbounds %"struct.std::pair", ptr %4, i32 %__n
```
but now it's
```
%incdec.ptr = getelementptr inbounds i8, ptr %2, i32 %.sink1
```
This results in an incorrect offset for `%add.ptr = getelementptr inbounds %"struct.std::pair", ptr %4, i32 %__n` since we'd now just add `%.sink1` bytes (where `%.sink1 = %__n` which is the second argument), whereas before we'd add `%__n * 8` bytes (where 8 is the sizeof `%"struct.std::pair"`).
The before ASM is:
```
__advance:
ldr r2, [r0]
add.w r1, r2, r1, lsl #3
str r1, [r0]
bx lr
```
but the after asm is:
```
__advance:
ldr r2, [r0]
add r1, r2
str r1, [r0]
bx lr
```
The GEP should not be a candidate for sinking.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85323] 17.0.6 misc-include-cleaner requires header providing "true"/"false"
Issue 85323 Summary 17.0.6 misc-include-cleaner requires header providing "true"/"false" Labels Assignees Reporter artemisveizi I think this is a false positive. My understanding is that `true` and `false` are built in to the language, and should not need an explicit #include. I get the following warnings from clang-tidy: ``` pmanager.h:47:24: warning: no header providing "true" is directly included [misc-include-cleaner] 15 | return true; | ^ ``` ``` pmanager:50:16: warning: no header providing "false" is directly included [misc-include-cleaner] 15 | return false; |^ ``` Just to try and resolve this, I #include . This does not resolve the warnings above, and instead adds the warning: "`included header cstdbool is not used directly [misc-include-cleaner]`" This seems like an error, based on my understanding of the documentation. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85313] missed fold, x / c < x => x > 0
Issue
85313
Summary
missed fold, x / c < x => x > 0
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/yG_wxp
https://godbolt.org/z/fKo893Pv1
```llvm
define i1 @src(i32 %0, i1 %1, i1 %2, i1 %3, i8 %4) {
if.then160:
%5 = sdiv i32 %0, 131313
%6 = icmp slt i32 %5, %0
ret i1 %6
}
define i1 @tgt(i32 %0, i1 %1, i1 %2, i1 %3, i8 %4) {
if.then160:
%5 = icmp sgt i32 %0, 0
ret i1 %5
}
```
Constant c 131313 can be anything but 0 or 1.
@dtcxzyw @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85289] [libc] implement pipe2
Issue 85289 Summary [libc] implement pipe2 Labels good first issue, libc Assignees Reporter michaelrj-google The pipe2 is defined on linux here: https://man7.org/linux/man-pages/man2/pipe.2.html This is a simple syscall wrapper, so implementation should be straightforward. ### Build System In [entrypoints.txt](https://github.com/llvm/llvm-project/blob/main/libc/config/linux/x86_64/entrypoints.txt) - [ ] Add the new function to the list of entrypoints for unistd.h (you need to do this before it will build) In [unistd/CMakeLists.txt](https://github.com/llvm/llvm-project/blob/main/libc/src/unistd/CMakeLists.txt) - [ ] Add new entrypoint objects to the list - [ ] Also add it to the list for unistd/linux/CMakeLists.txt In [linux.td](https://github.com/llvm/llvm-project/blob/main/libc/spec/linux.td) - [ ] Add the functions to the list of functions for unistd.h (this can be confusing, ask for help if you're stuck). ### Code Create `unistd/pipe2.h` - [ ] look at [dup.h](https://github.com/llvm/llvm-project/blob/main/libc/src/unistd/dup.h) for an example of how this should be laid out (copying the whole file and modifying it is fine). Create `unistd/linux/pipe2.cpp` - [ ] Again, look at look at [linux/dup.cpp](https://github.com/llvm/llvm-project/blob/main/libc/src/unistd/linux/dup.cpp) for an example. ### Testing Create `test/src/unistd/pipe2_test.cpp` - [ ] This needs to test the function succeeding and failing - [ ] This is only testing the code you wrote, so don't worry too much about testing parts of the interface that the kernel handles. Add your tests to [test/src/unistd/CMakeLists.txt](https://github.com/llvm/llvm-project/blob/main/libc/test/src/unistd/CMakeLists.txt) - [ ] Hopefully self-explanatory ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85287] [libc][POSIX] implement fseeko, ftello
Issue 85287 Summary [libc][POSIX] implement fseeko, ftello Labels libc Assignees Reporter nickdesaulniers https://pubs.opengroup.org/onlinepubs/9699919799/functions/fseeko.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/ftello.html Specifically the "o" variants of fseek and ftell are being used explicitly by libc++'s LIBCXX_ENABLE_WIDE_CHARACTERS . ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85286] [libc][math][c23] Implement canonicalize functions.
Issue 85286 Summary [libc][math][c23] Implement canonicalize functions. Labels good first issue Assignees Reporter lntue This is defined in C23 standard: section 7.12.11.7 in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Need to support the following data types: float, single, double, float128. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85284] [libc] implement __errno_location
Issue 85284 Summary [libc] implement __errno_location Labels libc Assignees Reporter nickdesaulniers Linux standard base defines this function: http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/baselib---errno-location.html . I've seen it referenced by libc++.so (but not explicitly in source). We may need this at some point for compatibility, but it's not high priority. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85283] [libc][math][c23] Implement C23 math functions nextup, nextdown.
Issue 85283 Summary [libc][math][c23] Implement C23 math functions nextup, nextdown. Labels good first issue Assignees Reporter lntue These functions are defined in C23 standard: section 7.12.11.5 and 7.12.11.6 in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf Could simply be implemented using `fputil::nextafter` template. Need to support the following data types: float, double, long double, float128. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85282] [libc] implement pthread condition variable support (pthread_cond_*)
Issue 85282 Summary [libc] implement pthread condition variable support (pthread_cond_*) Labels libc Assignees Reporter nickdesaulniers int [pthread_cond_broadcast](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_broadcast.html)(pthread_cond_t *); int [pthread_cond_destroy](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_destroy.html)(pthread_cond_t *); int [pthread_cond_init](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_init.html)(pthread_cond_t *, const pthread_condattr_t *); int [pthread_cond_signal](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_signal.html)(pthread_cond_t *); int [pthread_cond_timedwait](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_timedwait.html)(pthread_cond_t *, pthread_mutex_t *, const struct timespec *); int [pthread_cond_wait](https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_wait.html)(pthread_cond_t *, pthread_mutex_t *); Specifically, FWICT libc++ depends on: ``` pthread_cond_broadcast pthread_cond_destroy pthread_cond_signal pthread_cond_timedwait pthread_cond_wait ``` (but not pthread_cond_init??) I don't think we implement any of these. We'll likely need to implement pthread_cond_init first to begin testing the rest. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85281] SIGSEGV under DenseMapBase::erase after std::bad_alloc
Issue 85281 Summary SIGSEGV under DenseMapBase::erase after std::bad_alloc Labels new issue Assignees Reporter cuviper Ref: https://github.com/rust-lang/rust/issues/121305 In that Rust issue, running on an `i686` host, I found that `DenseMap::allocateBuckets` -> `llvm::allocate_buffer` -> `operator new` was throwing `std::bad_alloc`. Then when unwinding runs the destructors into `LLVMContextDispose`, we get back into `DenseMapBase::erase` and hit `SIGSEGV`, presumably in the same instance that failed allocation. Maybe `allocate_buffer` should catch and call `report_bad_alloc_error` like the `safe_*alloc` functions do? But even so, it seems that some part of `DenseMap` is not exception safe. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85279] [libc][math][c23] Implement C23 math functions fromfp, fromfpx, ufromfp, ufromfpx
Issue 85279 Summary [libc][math][c23] Implement C23 math functions fromfp, fromfpx, ufromfp, ufromfpx Labels libc Assignees Reporter lntue These functions are defined in C23 standard: section 7.12.9.10 and 7.12.9.11 in https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf. We will need to adapt our current rounding functions to extra requirements of these functions. Need to support the following data types: float, double, long double, and float128. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85278] [libc] implement pthread_mutex_trylock
Issue 85278 Summary [libc] implement pthread_mutex_trylock Labels libc Assignees Reporter nickdesaulniers pthread_mutex_trylock is necessary for supporting libc++ (todo(@nickdesaulniers ): perhaps just LIBCXX_ENABLE_THREADS) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85276] Add headergen details to entrypoint implementation guide
Issue 85276 Summary Add headergen details to entrypoint implementation guide Labels documentation, libc Assignees michaelrj-google Reporter michaelrj-google https://libc.llvm.org/dev/implementation_standard.html This needs to explain - [ ] Adding the entrypoint in spec/.td - [ ] Adding the entrypoint to entrypoints.txt - [ ] Adding tests ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85275] [libc] implement ioctl
Issue 85275 Summary [libc] implement ioctl Labels good first issue, libc Assignees Reporter nickdesaulniers the ioctl syscall is pretty important, and is used by libc++ for LIBCXX_ENABLE_RANDOM_DEVICE support. We currently define a few macros for ioctl in include/llvm-libc-macros/sys-ioctl-macros.h and generate ioctl.h via include/sys/ioctl.h.def. I also see open coded calls to ioctl in: - src/unistd/linux/isatty.cpp - src/termios/linux/tcgetattr.cpp - src/termios/linux/tcsendbreak.cpp - src/termios/linux/tcgetsid.cpp - src/termios/linux/tcdrain.cpp - src/termios/linux/tcsetattr.cpp - src/termios/linux/tcflush.cpp - src/termios/linux/tcflow.cpp I assume once ioctl is implemented, all of the above open coded calls should be replaced with the call to our internal wrapper. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85273] Machine Outliner does not consider bundles
Issue 85273 Summary Machine Outliner does not consider bundles Labels new issue Assignees Reporter AtariDreams Currently the vectors do not take bundles into account, causing it to outline bundled instructions to different functions in some cases. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85268] missed fold, sext(fptosi x to i32) => fptosi x to i64
Issue
85268
Summary
missed fold, sext(fptosi x to i32) => fptosi x to i64
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/bFW9vZ
online Alive timed out for this one, you'll need local alive2 with larger smt-to.
```llvm
define i64 @src(float %0) {
if.end27:
%1 = fptosi float %0 to i32
%2 = sext i32 %1 to i64
ret i64 %2
sink: ; No predecessors!
unreachable
}
define i64 @tgt(float %0) {
if.end27:
%1 = fptosi float %0 to i64
ret i64 %1
sink: ; No predecessors!
unreachable
}
```
no brainer, same pattern applies to fptoui.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85267] missed fold, x * C1 > C2 => x > C2
Issue
85267
Summary
missed fold, x * C1 > C2 => x > C2
Labels
new issue
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/UmK7vQ
https://godbolt.org/z/a6Gqfvxv8
```llvm
define i1 @src(float %0) {
%t1 = fmul float %0, 0x3FF0C000
%t2 = fcmp olt float %t1, 0x3FE20418A000
ret i1 %t2
}
define i1 @tgt(float %0) {
%ole = fcmp ole float %0, 0x3FE12878E000
ret i1 %ole
}
```
generalization may be a little tricky for this one.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85265] missed optimization, fptrunc (x) >= C1 => x >= C2
Issue
85265
Summary
missed optimization, fptrunc (x) >= C1 => x >= C2
Labels
new issue
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/n53up6
https://godbolt.org/z/q6vrbxTo3
```llvm
define i1 @src(double %0) {
if.end155:
%1 = fptrunc double %0 to float
%2 = fcmp oge float %1, 1.00e+02
ret i1 %2
}
define i1 @tgt(double %0) {
if.end155:
%oge = fcmp oge double %0, 0x4058F000
ret i1 %oge
}
```
Other variants may follow the same patterns.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85257] Optimizing (x & (-1 << y)) to ((x >> y) << y) or vice versa
Issue
85257
Summary
Optimizing (x & (-1 << y)) to ((x >> y) << y) or vice versa
Labels
new issue
Assignees
Reporter
Explorer09
### Test code
```c
#include
unsigned int func1(unsigned int x, unsigned char count)
{
return (x >> count) << count;
}
unsigned int func2(unsigned int x, unsigned char count)
{
return x & (~0U << count);
}
uint16_t func3(uint16_t x, unsigned char count)
{
return (x >> count) << count;
}
uint16_t func4(uint16_t x, unsigned char count)
{
return x & (0x << count);
}
```
### Expected result
`func1` and `func2` should compile to identical code. The compiler should pick the pattern that produces the smallest or fastest code for the target processor. (Clang already did this right.)
`func3` and `func4` should compile to identical code, too. If the ABI doesn't require the upper bits of the registers to be zeroed, then `func3` and `func4` code size could be as small as `func1` and `func2`.
### Current result (clang)
clang 18.1.0 and "-Os" option
(Tested in Compiler Explorer (godbolt.org))
`func1`, `func2` and `func3` produce identical code in x86-64. It seems that clang does recognize the pattern and optimize accordingly.
For x86-64 target, `((x >> count) << count)` is used.
For ARM and RISC-V targets, `((-1 << count) & x)` is used.
However clang doesn't recognize `func4` as identical to `func3`, so there are rooms to improve. (`func4` is the real case I was facing. I only need to work with a 16-bit input value and I don't want to internally promote to `uint32_t` just for optimization purpose.)
### Notes
I also reported this in GCC bug tracker:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85256] Clang crash when use libc++ with valid code
Issue
85256
Summary
Clang crash when use libc++ with valid code
Labels
libc++,
clang:frontend,
crash-on-valid
Assignees
Reporter
yronglin
https://godbolt.org/z/E6bPTGoTx
stack trace
```
clang++: /root/llvm-project/clang/lib/AST/ExprConstant.cpp:6456: bool HandleConstructorCall(const clang::Expr*, const {anonymous}::LValue&, {anonymous}::CallRef, const clang::CXXConstructorDecl*, {anonymous}::EvalInfo&, clang::APValue&): Assertion `Info.Ctx.hasSameType(BaseIt->getType(), BaseType) && "base class initializers not in expected order"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/clang++ -gdwarf-4 -g -o /app/output.s -mllvm --x86-asm-syntax=intel -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics -fno-crash-diagnostics -std=c++20 -O0 -stdlib=libc++
1. :17:45: current parser token ';'
2. :16:12: parsing function body 'main'
3. :16:12: in compound statement ('{}')
#0 0x039011e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x39011e8)
#1 0x038feecc llvm::sys::CleanupOnSignal(unsigned long) (/opt/compiler-explorer/clang-assertions-trunk/bin/clang+++0x38feecc)
#2 0x038469e8 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
#3 0x7fe4edc42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
#4 0x7fe4edc969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
#5 0x7fe4edc42476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
#6 0x7fe4edc287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
#7 0x7fe4edc2871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b)
#8 0x7fe4edc39e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#9 0x0741c7e2 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#10 0x0741c95f HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#11 0x0741cb84 (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) ExprConstant.cpp:0:0
#12 0x074209a2 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#13 0x07422b08 EvaluateRecord(clang::Expr const*, (anonymous namespace)::LValue const&, clang::APValue&, (anonymous namespace)::EvalInfo&) ExprConstant.cpp:0:0
#14 0x073ead1d EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) ExprConstant.cpp:0:0
#15 0x0741b9e2 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#16 0x0741c95f HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#17 0x0741cb84 (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) ExprConstant.cpp:0:0
#18 0x074209a2 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#19 0x07422b08 EvaluateRecord(clang::Expr const*, (anonymous namespace)::LValue const&, clang::APValue&, (anonymous namespace)::EvalInfo&) ExprConstant.cpp:0:0
#20 0x073ead1d EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) ExprConstant.cpp:0:0
#21 0x0741b9e2 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, (anonymous namespace)::CallRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#22 0x0741c95f HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) ExprConstant.cpp:0:0
#23 0x0741cb84 (anonymous namespace)::RecordExprEvaluator::VisitCXXConstructExpr(clang::CXXConstructExpr const*, clang::QualType) ExprConstant.cpp:0:0
#24 0x074209a2 clang::StmtVisitorBase::Visit(clang::Stmt const*) ExprConstant.cpp:0:0
#25 0x07421c98 clang::St
[llvm-bugs] [Bug 85254] [DebugInfo][RemoveDIs] Phi nodes and debug records
Issue 85254 Summary [DebugInfo][RemoveDIs] Phi nodes and debug records Labels new issue Assignees Reporter rgwott The works discussed in [1] caused a regression downstream that can be reproduced upstream. We understand this is some weird interaction of the removal of debug intrinsics with phi nodes in some cases. Until recently the error message was something else but [2] changed the error: ``` clang: /data_nvme1n1/llvm/llvm-project/llvm/lib/IR/Instruction.cpp:163: void llvm::Instruction::insertBefore(llvm::BasicBlock&, llvm::iplist_impl >, llvm::SymbolTableListTraits > >::iterator): Assertion !isa(this) && "Inserting PHI after debug-records!" 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: build/bin/clang -c -O1 --target=arm-arm-none-eabi -march=armv8.1-m.main -g /tmp/repro.c -o /tmp/repro.bin 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/tmp/repro.c'. 4. Running pass 'Hardware Loop Insertion' on function '@func1' #0 0x5609005d2030 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build/bin/clang+0x3fb4030) #1 0x5609005cf43f llvm::sys::RunSignalHandlers() (build/bin/clang+0x3fb143f) #2 0x560900515d78 CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #3 0x7f9b95242520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7f9b952969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc) #5 0x7f9b95242476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476) #6 0x7f9b952287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3) #7 0x7f9b9522871b (/lib/x86_64-linux-gnu/libc.so.6+0x2871b) #8 0x7f9b95239e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #9 0x5608ffee54a2 (build/bin/clang+0x38c74a2) #10 0x5608ffee54db llvm::Instruction::insertInto(llvm::BasicBlock*, llvm::ilist_iterator_w_bits, false, false>) (build/bin/clang+0x38c74db) #11 0x5608ffed3437 llvm::IRBuilderDefaultInserter::InsertHelper(llvm::Instruction*, llvm::Twine const&, llvm::BasicBlock*, llvm::ilist_iterator_w_bits, false, false>) const (build/bin/clang+0x38b5437) #12 0x5608ff82b002 (anonymous namespace)::HardwareLoopsImpl::TryConvertLoop(llvm::Loop*, llvm::LLVMContext&) HardwareLoops.cpp:0:0 #13 0x5608ff82da91 (anonymous namespace)::HardwareLoopsLegacy::runOnFunction(llvm::Function&) (.part.0) HardwareLoops.cpp:0:0 #14 0x5608fff3cf7e llvm::FPPassManager::runOnFunction(llvm::Function&) (build/bin/clang+0x391ef7e) #15 0x5608fff3d1c9 llvm::FPPassManager::runOnModule(llvm::Module&) (build/bin/clang+0x391f1c9) #16 0x5608fff3db35 llvm::legacy::PassManagerImpl::run(llvm::Module&) (build/bin/clang+0x391fb35) #17 0x56090083ff76 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*) (build/bin/clang+0x4221f76) #18 0x560900e48b67 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (build/bin/clang+0x482ab67) #19 0x56090295ed8c clang::ParseAST(clang::Sema&, bool, bool) (build/bin/clang+0x6340d8c) #20 0x5609010dc2a9 clang::FrontendAction::Execute() (build/bin/clang+0x4abe2a9) #21 0x5609010558e5 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (build/bin/clang+0x4a378e5) #22 0x5609011ad5e5 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (build/bin/clang+0x4b8f5e5) #23 0x5608fd77cde9 cc1_main(llvm::ArrayRef, char const*, void*) (build/bin/clang+0x115ede9) #24 0x5608fd775053 ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0 #25 0x560900e8d7dd void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0 #26 0x560900516240 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (build/bin/clang+0x3ef8240) #27 0x560900e8e05e clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) const (.part.0) Job.cpp:0:0 #28 0x560900e538ea clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (build/bin/clang+0x48358ea) #29 0x560900e543bd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const (build/bin/clang+0x48363bd) #30 0x560900e61224 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl>&) (build/bin/clang+0x4843224) #31 0x5608fd77a155 clang_main(int
[llvm-bugs] [Bug 85253] support AUTOSAR C++14 A7-5-1 bugprone-return-const-ref-from-parameter
Issue
85253
Summary
support AUTOSAR C++14 A7-5-1 bugprone-return-const-ref-from-parameter
Labels
clang-tidy,
check-request
Assignees
Reporter
HerrCai0907
> AUTOSAR C++14 A7-5-1
> A function shall not return a reference or a pointer to a parameter that is passed by reference to const.
[example](https://godbolt.org/z/9zMEco9E3)
```c++
struct S {
S();
S(S const&);
~S();
};
S const& f(S const &a) { return a; }
S f() {
S const & a = f(S{}); // object referenced by 'a' has destructed after this statement
return a; // bugprone
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85251] missed fold, fneg(t ? c1 : c2) => t ? -c1 : -c2
Issue
85251
Summary
missed fold, fneg(t ? c1 : c2) => t ? -c1 : -c2
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/RWUbrQ
https://godbolt.org/z/qd5Tqbrzc
```llvm
define float @src(i1 %0) {
entry:
%t2 = select i1 %0, float -1.00e+00, float 1.00e+00
%t3 = fneg float %t2
ret float %t3
}
define float @tgt(i1 %0) {
entry:
%sel = select i1 %0, float 1.00e+00, float -1.00e+00
ret float %sel
}
```
@jayfoad @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85250] missed fold, (x > 0) ? x : -x == 0 => x == 0
Issue
85250
Summary
missed fold, (x > 0) ? x : -x == 0 => x == 0
Labels
llvm:instcombine
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/NFEKjp
https://godbolt.org/z/7Ef9Kf4s3
```llvm
define i1 @src(float %0) {
entry:
%1 = fcmp oge float %0, 0.00e+00
%2 = fneg float %0
%3 = select i1 %1, float %0, float %2
%4 = fcmp oeq float %3, 0.00e+00
ret i1 %4
}
define i1 @tgt(float %0) {
entry:
%oeq = fcmp oeq float %0, 0.00e+00
ret i1 %oeq
}
```
@jayfoad @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85245] missed fold, fcmp ogt (x - y), 0 => fcmp ogt x, y
Issue
85245
Summary
missed fold, fcmp ogt (x - y), 0 => fcmp ogt x, y
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/azHAHq
https://godbolt.org/z/M8WbdYE8x
```llvm
define i1 @src(float %0, float %1) {
%t2 = fsub float %0, %1
%t3 = fcmp ogt float %t2, 0.00e+00
ret i1 %t3
}
define i1 @tgt(float %0, float %1) {
%olt = fcmp ogt float %0, %1
ret i1 %olt
}
```
@jayfoad @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85244] missed fold: poisonous vector element
Issue
85244
Summary
missed fold: poisonous vector element
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/N3FSo8
https://godbolt.org/z/GMn7sqTxj
```llvm
define <2 x double> @src(double %0, double %1, i1 %2, i1 %3, i1 %4) {
if.end:
%5 = fadd double %1, -1.0
%6 = insertelement <2 x double> poison, double %0, i64 0
%7 = insertelement <2 x double> %6, double %5, i64 1
%8 = fadd <2 x double> %7,
ret <2 x double> %8
}
define <2 x double> @tgt(double %0, double %1, i1 %2, i1 %3, i1 %4) {
%6 = insertelement <2 x double> poison, double %0, i64 0
%7 = fadd <2 x double> %6,
ret <2 x double> %7
}
```
@jayfoad @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85243] support AUTOSAR C++14 Rule A7-2-4 readability-enum-value
Issue 85243 Summary support AUTOSAR C++14 Rule A7-2-4 readability-enum-value Labels clang-tidy, check-request Assignees Reporter HerrCai0907 In AUTOSAR C++14 Rule A7-2-4 > Rule A7-2-4 (required, implementation, automated) > In an enumeration, either (1) none, (2) the first or (3) all enumerators shall be initialized. This check want to detect explicit initialization of a part of enumerators in an enumeration, and relying on compiler to initialize the others. It causes readability issues. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85242] [libc++] Modules tests keep failing on the release/18.x branch
Issue 85242 Summary [libc++] Modules tests keep failing on the release/18.x branch Labels libc++ Assignees ldionne Reporter ldionne We should disable the since it borks the rest of the CI. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85241] missed fold: (fmul * 0) * constant => fmul * 0
Issue
85241
Summary
missed fold: (fmul * 0) * constant => fmul * 0
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
zhengyang92
https://alive2.llvm.org/ce/z/bKDTJd
https://godbolt.org/z/v1qYrb5Ka
```llvm
define float @src(float %0) {
entry:
%1 = fmul float %0, 0.00e+00
%2 = fmul float %1, 3.00e+00
ret float %2
}
define float @tgt(float %0) {
entry:
%1 = fmul float %0, 0.00e+00
ret float %1
}
```
@jayfoad @regehr
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85237] [lldb-dap] Support for Swift
Issue 85237 Summary [lldb-dap] Support for Swift Labels new issue Assignees Reporter wojciech-kulik Please consider adding support for Swift in `lldb-dap`, currently the debugger is unable to show correctly local variables and frames. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85234] Backport d9b435c24ddd and a41bcb393053 to 18.x
Issue 85234 Summary Backport d9b435c24ddd and a41bcb393053 to 18.x Labels new issue Assignees Reporter SixWeining /cherry-pick d9b435c24ddd a41bcb393053 These two patches fix sanitizer buildbot failure: https://lab.llvm.org/buildbot/#/builders/5/builds/41530/steps/9/logs/stdio ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85233] Switch warnings with -Weverything on clang 18
Issue
85233
Summary
Switch warnings with -Weverything on clang 18
Labels
clang
Assignees
Reporter
omajid
With clang 18, when using the -Weverything flag with code involving switches, I get switch-related warnings no matter what I do.
If the switches are exhaustive. `clang -Weverything` complains the switch is missing a `default`:
```
$ cat test.c
#include
typedef enum {
ZERO = 0,
_ONE_ = 1,
} Number;
int test(Number number);
int test(Number number)
{
switch (number)
{
case ZERO:
return 0;
case ONE:
return 1;
}
assert(0);
return -1;
}
$ clang -c test.c -o test.o -Wall -Weverything
test.c:13:2: warning: 'switch' missing 'default' label [-Wswitch-default]
13 | switch (number)
| ^
1 warning generated.
```
When `default` is present, clang complains that the switch is exhaustive and `default` shouldn't be used:
```
$ cat test.c
typedef enum {
ZERO = 0,
_ONE_ = 1,
} Number;
int test(Number number);
int test(Number number)
{
switch (number)
{
case ZERO:
return 0;
case ONE:
return 1;
default:
assert(0);
return -1;
}
assert(0);
return -1;
}
$ clang -c test.c -o test.o -Wall -Weverything
test.c:19:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
19 | default:
| ^
1 warning generated.
```
What can I do to make clang happy?
Environment:
```
$ clang --version
clang version 18.1.0 (Fedora 18.1.0~rc4-2.fc40)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/clang.cfg
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85226] [TSan] Invalid IR generated for atomicrmw with pointers
Issue
85226
Summary
[TSan] Invalid IR generated for atomicrmw with pointers
Labels
compiler-rt:tsan
Assignees
Reporter
nikic
https://llvm.godbolt.org/z/o3nej9cKj
```llvm
; RUN: opt -S -passes=tsan
define void @atomic8_xchg_monotonic_ptr(ptr %a, ptr %b) {
entry:
atomicrmw xchg ptr %a, ptr %b monotonic
ret void
}
```
This produces:
```llvm
define void @atomic8_xchg_monotonic_ptr(ptr %a, ptr %b) {
entry:
%0 = call ptr @llvm.returnaddress(i32 0)
call void @__tsan_func_entry(ptr %0)
%1 = zext ptr %b to i64
%2 = call i64 @__tsan_atomic64_exchange(ptr %a, i64 %1, i32 0)
call void @__tsan_func_exit()
ret void
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85223] [BitInt] Expose a _BitInt literal suffix in C++
Issue 85223 Summary [BitInt] Expose a _BitInt literal suffix in C++ Labels good first issue Assignees Reporter erichkeane The C literal suffix for _BitInt is 'wb' or 'WB' (also allows a 'u' modifier for unsigned). We expose _BitInt in C++ as an extension, but do NOT expose the suffix, as it is one that the C++ committee might choose to use something else. We should NOT do a single underscore, as that is reserved for the user defined literals (https://eel.is/c++draft/usrlit.suffix). However, that standardeeze allows double-underscores for use by the implementation, so we could implement this with double-underscores without problem! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85220] Unsupported expression in static initializer
Issue
85220
Summary
Unsupported _expression_ in static initializer
Labels
new issue
Assignees
Reporter
Tt421
The following error occurred when I tried to convert the following `.ll` file to a `.wasm` file.
run command: `llc string.ll -filetype=obj -mtriple=wasm32 -o string.wasm`
The content of `string.ll` is:
```
; ModuleID = 'string.bc'
source_filename = "default"
target datalayout = "e-m:e-p:32:32-p10:8:8-p20:8:8-i64:64-n32:64-S128-ni:1:10:20"
target triple = "wasm32-unknown-unknown"
@test = internal constant { i8 addrspace(1)* } { i8 addrspace(1)* addrspacecast ({ i8* }* @cons to i8 addrspace(1)*) }
@cons = internal constant { i8* } zeroinitializer
```
The content of error is:
```
LLVM ERROR: Unsupported _expression_ in static initializer: addrspacecast (i8* bitcast ({ i8* }* @"$const" to i8*) to i8 addrspace(1)*)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc string.ll -filetype=obj -mtriple=wasm32 -o add.wasm
#0 0x55d0f1349363 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x49de363)
#1 0x55d0f13472ce llvm::sys::RunSignalHandlers() (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x49dc2ce)
#2 0x55d0f13496ff SignalHandler(int) Signals.cpp:0:0
#3 0x7fb06a298420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#4 0x7fb069d7700b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
#5 0x7fb069d56859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
#6 0x55d0f12bedc2 llvm::report_fatal_error(llvm::Twine const&, bool) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x4953dc2)
#7 0x55d0f06d753c (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x3d6c53c)
#8 0x55d0f06d795a emitGlobalConstantImpl(llvm::DataLayout const&, llvm::Constant const*, llvm::AsmPrinter&, llvm::Constant const*, unsigned long, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>*) AsmPrinter.cpp:0:0
#9 0x55d0f06d9c07 emitGlobalConstantStruct(llvm::DataLayout const&, llvm::ConstantStruct const*, llvm::AsmPrinter&, llvm::Constant const*, unsigned long, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>*) AsmPrinter.cpp:0:0
#10 0x55d0f06d78ec emitGlobalConstantImpl(llvm::DataLayout const&, llvm::Constant const*, llvm::AsmPrinter&, llvm::Constant const*, unsigned long, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>*) AsmPrinter.cpp:0:0
#11 0x55d0f06cd9af llvm::AsmPrinter::emitGlobalConstant(llvm::DataLayout const&, llvm::Constant const*, llvm::DenseMap, llvm::DenseMapInfo, llvm::detail::DenseMapPair>>*) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x3d629af)
#12 0x55d0f06cd2be llvm::AsmPrinter::emitGlobalVariable(llvm::GlobalVariable const*) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x3d622be)
#13 0x55d0f06d3857 llvm::AsmPrinter::doFinalization(llvm::Module&) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x3d68857)
#14 0x55d0f0c4ab81 llvm::FPPassManager::doFinalization(llvm::Module&) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x42dfb81)
#15 0x55d0f0c44f61 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x42d9f61)
#16 0x55d0ef514dbf main (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x2ba9dbf)
#17 0x7fb069d58083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#18 0x55d0ef50ff3a _start (/home/t/clang+llvm-15.0.5-x86_64-linux-gnu-ubuntu-18.04/bin/llc+0x2ba4f3a)
Aborted (core dumped)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85214] [MacroFusion][RISCV] Make commutable instructions fusible as possible
Issue 85214 Summary [MacroFusion][RISCV] Make commutable instructions fusible as possible Labels new issue Assignees Reporter wangpc-pp In https://github.com/llvm/llvm-project/issues/82738, the user raised a issue about commutable instuctions. I have created a PR (https://github.com/llvm/llvm-project/pull/82751) to fix it, but it comes another problem: what if the μ-arch can fuse the instruction pair only if `rs1` matches? For example, for `slli+add` fusion (see https://godbolt.org/z/xo6xEoPKe): ``` slli r0, r0, 1 add r0, r0, r1 // fusible slli r0, r0, 1 add r0, r1, r0 // fusible ``` The μ-arch may not check `rs2`, but `add` is commutable, we can't guarantee that `r0` will always be in `rs1`. In InstCombine, we have `InstCombinerImpl::SimplifyAssociativeOrCommutative`: ``` /// This performs a few simplifications for operators that are associative or /// commutative: /// /// Commutative operators: /// /// 1. Order operands such that they are listed from right (least complex) to /// left (most complex). This puts constants before unary operators before /// binary operators. ``` But do we need or have a way in backend to change the operands order of second instruction when it's commutable? cc @dtcxzyw @topperc ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 65993 in oss-fuzz: llvm: Fuzzing build failure
Comment #9 on issue 65993 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65993#c9 Friendly reminder that the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-b4913627-7b4e-42f6-83d1-161e21c20f5c.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85209] [GlobalISel] Hash collisions / hitting EmptyKey or TombstoneKey on map key in RegisterBankInfo
Issue 85209 Summary [GlobalISel] Hash collisions / hitting EmptyKey or TombstoneKey on map key in RegisterBankInfo Labels new issue Assignees Reporter marcauberer We experience sporadic failures in [RegisterBankInfo::getOperandsMapping](https://github.com/llvm/llvm-project/blob/203757776826cfd164c537048ec90f5ada50cae2/llvm/lib/CodeGen/RegisterBankInfo.cpp#L334). These failures seem to be triggered by `hash_code Hash = hash_combine_range(Begin, End);` hitting the value of EmptyKey or TombstoneKey in the DenseMap member [MapOfOperandsMappings](https://github.com/llvm/llvm-project/blob/203757776826cfd164c537048ec90f5ada50cae2/llvm/include/llvm/CodeGen/RegisterBankInfo.h#L413). We still use LLVM 13, but the coding seems to have remained the same until to date. We also see failures in [RegisterBankInfo::ValueMapping::verify](https://github.com/llvm/llvm-project/blob/203757776826cfd164c537048ec90f5ada50cae2/llvm/lib/CodeGen/RegisterBankInfo.cpp#L555) that seem to be triggered by hash collisions from `hash_code Hash = hash_combine_range(Begin, End);` To us it seems that this coding is not protected against these problems and therefore failures can happen randomly. Already posted the problem in the Forum, but got no answer there: https://discourse.llvm.org/t/registerbankinfo-getoperandsmapping-not-protected-against-hash-collisions-emptykey-tombstonekey/77659 ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85202] Anchored Addresses to reduce global address calculation
Issue 85202 Summary Anchored Addresses to reduce global address calculation Labels new issue Assignees Reporter sjoerdmeijer GCC has a feature to anchor addresses, which calculates a base address for global variables and uses offsets to that base address to access globals. This saves instructions to materialise the addresses of globals on some architectures, on AArch64 for example: https://godbolt.org/z/qbn6rTbf8 The GCC feature is described in a bit more detail here: https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gccint/Anchored-Addresses.html This is related to PR #56392, but that might be more focused on a RISC-V, like enabling the GlobalMerge pass. About the difference between anchored addresses and GlobalMerge: GlobalMerge is a relative simple pass that tries to merge internal globals, so it is less generic than anchored addresses. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85196] [SimplifyCFG] Missed optimization: merge switch branches into default if they hold the same value in phi as the default branch
Issue
85196
Summary
[SimplifyCFG] Missed optimization: merge switch branches into default if they hold the same value in phi as the default branch
Labels
new issue
Assignees
Reporter
XChy
Alive2 proof: https://alive2.llvm.org/ce/z/8U-LhB
### Motivating example
```llvm
define i64 @src(i32 %cmd) #0 {
entry:
switch i32 %cmd, label %sw.default [
i32 1, label %sw.bb2
i32 11, label %sw.epilog
i32 13, label %sw.bb1
i32 0, label %sw.bb1
]
sw.bb1: ; preds = %entry, %entry
br label %sw.epilog
sw.bb2: ; preds = %entry
br label %sw.epilog
sw.default: ; preds = %entry
br label %sw.epilog
sw.epilog: ; preds = %entry, %sw.default, %sw.bb2, %sw.bb1
%ret = phi i64 [ 0, %sw.default ], [ 0, %sw.bb1 ], [ 1, %entry ], [ 1, %sw.bb2 ]
ret i64 %ret
}
```
`switch(13)` and `switch(0)` produce the same `%ret` as default case:
```llvm
define i64 @tgt(i32 %cmd) #0 {
entry:
switch i32 %cmd, label %sw.epilog [
i32 1, label %sw.bb2
i32 11, label %sw.bb1
]
sw.bb1: ; preds = %entry
br label %sw.epilog
sw.bb2: ; preds = %entry
br label %sw.epilog
sw.epilog: ; preds = %entry, %sw.bb2, %sw.bb1
%ret = phi i64 [ 1, %sw.bb1 ], [ 1, %sw.bb2 ], [ 0, %entry ]
ret i64 %ret
}
```
### Real-world motivation
This snippet of IR is derived from [openssl/crypto/bio/bss_conn.c@conn_ctrl](https://github.com/openssl/openssl/blob/c91f0ca95881d03a54aedee197bbf5c02935/crypto/bio/bss_conn.c#L447) (after O3 pipeline).
The example above is a reduced version. If you're interested in the original suboptimal IR and optimal IR, see also:https://godbolt.org/z/nndaqfM9e
**Let me know if you can confirm that it's an optimization opportunity, thanks.**
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85194] Instruction does not dominate all uses!
Issue 85194 Summary Instruction does not dominate all uses! Labels new issue Assignees Reporter dcb314 csmith $ source ./in-6bd2d7.sh Instruction does not dominate all uses! %20 = extractelement <2 x i8> %16, i64 1, !dbg !3021 %19 = sext i8 %20 to i16, !dbg !3021 in function func_47 fatal error: error in backend: Broken function found, compilation aborted! csmith $ Machine is an AMD Zen3. [in-6bd2d7.sh.gz](https://github.com/llvm/llvm-project/files/14598790/in-6bd2d7.sh.gz) [in-6bd2d7.c.gz](https://github.com/llvm/llvm-project/files/14598791/in-6bd2d7.c.gz) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85192] [clang] CTAD deduces alias template that does not satisfy the condition of the alias template
Issue
85192
Summary
[clang] CTAD deduces alias template that does not satisfy the condition of the alias template
Labels
clang
Assignees
Reporter
ImpleLee
The following code snippet fails `static_assert`, and the type of `i2` is inferred to be (as reported in the diagnostic message) `std::array, 1>`, which does not even constitute a legal `my_ints`.
Godbolt link: https://godbolt.org/z/1Mo9hz4W7 .
```c++
#include
#include
template
using my_ints = std::array;
int main() {
my_ints i = {1, 2, 3};
my_ints i2 = {i};
static_assert(std::is_same_v);
// error: static assertion failed due to requirement 'std::is_same_v, 1>, std::array>'
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 85190] [RISCV] Miscompile at -O3 with zbb
Issue
85190
Summary
[RISCV] Miscompile at -O3 with zbb
Labels
backend:RISC-V,
miscompilation
Assignees
Reporter
dtcxzyw
Reduced test case:
```
#include
#include
int8_t d;
int32_t b;
uint64_t c;
int64_t safe_add_func_int64_t_s_s(int64_t si1, int64_t si2)
{
return ((si1<0) && (si2<0) && (si1 < (INT64_MIN-si2))) ?
(si1) :
(si1 + si2);
}
int main() {
do b = safe_add_func_int64_t_s_s(c, 7 | c);
while (d);
printf("%d\n", b);
return 0;
}
```
```
> gcc -O0 test.c -fsanitize=undefined,address && ./a.out
7
> bin/clang -O3 -march=rv64gc_zbb test.c --target=riscv64-linux-gnu
> qemu-riscv64 -L /usr/riscv64-linux-gnu -cpu rv64,zbb=true ./a.out
0
```
cc @topperc @asb
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
