[llvm-bugs] [Bug 90010] Function sanitizer is extremely fragile on macOS
Issue
90010
Summary
Function sanitizer is extremely fragile on macOS
Labels
Assignees
Reporter
glandium
Because clang/llvm stores the function signature for runtime check as an integer preceding the function in the text section, and because symbols don't have explicit sizes in mach-O, as far as the linker knows, that data belongs to the function that precedes the "annotated" function.
So if you have function `foo` and function `bar`, the signature for `bar` belongs to `foo`. If for some reason, the linker removes `foo`, then the signature for `bar` becomes whatever the signature of `foo` was, and function call checks at runtime for indirect calls to bar fail.
There are two main situations where this can happen in practice: the `-dead_strip` linker flag (which removes dead code), and when `foo` is defined in multiple compilation units (e.g. template instantiations).
Here's a testcase for both cases:
`foo.h`:
```
template
int foo(T*) {
return 0;
}
```
`foo.cpp`
```
#include "foo.h"
int call(int(*cb)(int*), int* x) {
return cb(x);
}
int dead() {
return 42;
}
int(*bar)(int*) = ;
int main() {
return call(bar, 0);
}
```
`bar.cpp`:
```
#include "foo.h"
template int foo(void*);
template int foo(int*);
```
`baz.cpp`:
```
#include "foo.h"
template int foo(void*);
```
First case: build with `clang++ -o foo foo.cpp -fsanitize=function -fno-sanitize-recover=function -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -Wl,-dead_strip`
Fails with:
```
foo.cpp:4:10: runtime error: call to function int foo(int*) through pointer to incorrect function type 'int (*)(int *)'
(foo:arm64+0x13f24): note: int foo(int*) defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior foo.cpp:4:10
```
The reason it fails in this case is that the signature for the function `foo` is in `dead`, which is removed, so `foo` ends up with the signature of `dead`, from the last bytes of the function that precedes it. If `dead` had the same signature as `foo`, it would not fail, by mere chance.
Second case: build with `clang++ -o foo baz.cpp bar.cpp foo.cpp -fsanitize=function -fno-sanitize-recover=function -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk`
The failure output is the same as for the first case, but the reason is different. Because of the order of the .cpp files, `foo` comes from the instantiation in `bar.cpp`. Its signature is thus in `foo`. But `foo` is actually taken from the instantiation in `baz.cpp`, so practically speaking, this works as if `foo` in `bar.cpp` was dead code, so the signature for `foo` comes from the end of whatever was before `foo`, which in our case is text associated with no symbol at all at the beginning of `bar.cpp`, corresponding to the signature of `foo`.
Presumably, if clang emitted symbols for those function signatures, there wouldn't be a problem, because the linker wouldn't think the signature belongs to the preceding function.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 68239 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: verifyVPlanIsValid(*Plan) && "VPlan is invalid"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 68239 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: verifyVPlanIsValid(*Plan) && "VPlan is invalid" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68239#c1 ClusterFuzz testcase 5788250825359360 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm=202404160629:202404170622 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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 90009] Possible bug in compiler-rt 128x128 `wideMultiply`
Issue 90009 Summary Possible bug in compiler-rt 128x128 `wideMultiply` Labels new issue Assignees Reporter tgross35 [This bit of code](https://github.com/llvm/llvm-project/blob/49b209d0d1833a339e66735e1288c1805224603e/compiler-rt/lib/builtins/fp_lib.h#L145-L185) seems to have a bug where it is missing the carry bit. This was discovered when I was porting the function to Rust's compiler-rt and results of unit tests disagreed with Python, see https://github.com/rust-lang/compiler-builtins/pull/587#issuecomment-2060543566 and the followup discussion. To reproduce - `"0x * 0x` should be `0xfffe0001`, but this function returns `0xfffd0001`. cc @marthadev who found a fix for the Rust side. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90001] clang misleading diagnostic: error: 'f' requires 'float' type support, but ABI 'aapcs' does not support it
Issue
90001
Summary
clang misleading diagnostic: error: 'f' requires 'float' type support, but ABI 'aapcs' does not support it
Labels
clang,
clang:diagnostics
Assignees
Reporter
jroelofs
```
float f(void) { return 1.f; }
```
+
```
-mgeneral-regs-only
```
gives:
```
:1:7: error: 'f' requires 'float' type support, but ABI 'aapcs' does not support it
1 | float f(void) { return 1.f; }
| ^
1 error generated.
```
https://clang.godbolt.org/z/d3vGv9ahM
The diagnostic should blame `-mgeneral-regs-only` instead of the ABI, which has been modified by the flag.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 90000] `@min(@ctz(x), y)` can become `@ctz(x | (1 << y))`
Issue
9
Summary
`@min(@ctz(x), y)` can become `@ctz(x | (1 << y))`
Labels
new issue
Assignees
Reporter
Validark
[Godbolt link](https://zig.godbolt.org/z/fzMo9jYPK)
```zig
export fn bounded_tzcnt(x: u16) u8 {
return @min(@ctz(x), y);
}
export fn bounded_tzcnt_better(x: u16) u8 {
return @ctz(x | (1 << y));
}
export fn bounded_lzcnt(x: u16) u8 {
return @min(@clz(x), y);
}
export fn bounded_lzcnt_better(x: u16) u8 {
return @clz(x | (1 << 16 >> y));
}
```
```asm
bounded_tzcnt:
or edi, 65536
mov eax, 6
tzcnt ecx, edi
cmp cl, 6
cmovb eax, ecx
ret
bounded_tzcnt_better:
or edi, 64
tzcnt eax, edi
ret
bounded_lzcnt:
lzcnt cx, di
mov eax, 6
cmp cl, 6
cmovb eax, ecx
ret
bounded_lzcnt_better:
or edi, 1024
lzcnt ax, di
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89996] Bitmanipulations can be performed on vectors after they are moved over to scalar registers
Issue
89996
Summary
Bitmanipulations can be performed on vectors after they are moved over to scalar registers
Labels
new issue
Assignees
Reporter
Validark
This code:
```zig
export fn foo(v: @Vector(4, u8)) u32 {
return @bitCast(v & @as(@Vector(4, u8), @splat(0xF)));
}
```
Gives me:
```asm
.LCPI0_0:
.byte 15
.byte 15
.byte 15
.byte 15
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
.zero 1
foo:
vpand xmm0, xmm0, xmmword ptr [rip + .LCPI0_0]
vmovd eax, xmm0
ret
```
However, I can move the `&` to come after moving to a scalar register:
```zig
export fn bar(v: @Vector(4, u8)) u32 {
return @as(u32, @bitCast(v)) & 0x0F0F0F0F;
}
```
Emit:
```asm
bar:
vmovd eax, xmm0
and eax, 252645135
ret
```
https://zig.godbolt.org/z/jq1dfvboE
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89989] clang-include-cleaner: Consider supporting `IWYU pragma: no_include`
Issue 89989 Summary clang-include-cleaner: Consider supporting `IWYU pragma: no_include` Labels new issue Assignees Reporter crisluengo According to the documentation for clang-include-cleaner at , the IWYU pragma `no_include` is not supported (and I see it not having an effect in my IDE). Plenty of libraries are designed for the user to include a single header file, not any of the private implementation files, but don't have any IWYU pragmas to indicate this to clang-tidy. And let's be honest, it'll be a long time before all software is making good use of IWYU pragmas. As a user of these libraries, we can either turn off the misc-include-cleaner test in clang-tidy, or try to ignore the warnings in the IDE. Neither is ideal. If the library is open-source, of course, we could also submit a PR to the library in the hopes the owner cares. Currently the only way to suppress the warning is to add `// NOLINT(*-include-cleaner)` to each line that uses functionality from this library. This is of course highly impractical. A simple and practical solution for the user would be to add `// IWYU pragma: no_include "library/private/*"` to the source file. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89988] [SLPVectorizer][RISC-V] rv64gcv miscompile with `slp-vectorizer` pass
Issue
89988
Summary
[SLPVectorizer][RISC-V] rv64gcv miscompile with `slp-vectorizer` pass
Labels
new issue
Assignees
Reporter
patrick-rivos
Testcase:
```c
int d = 16;
unsigned a = 3;
short e[18], f[18];
unsigned short *g = e;
int main() {
for (long h = 0; h < 8; ++h) {
e[h] = -1;
f[h] = -2;
}
for (short h = 1; h; h += 5)
for (int i = 0; i < d; i += 4)
a = ({
int j = 40 ? g[i] <= (unsigned)(1 ? f[i] : 0) : 0;
a < j ? 0 : j;
});
__builtin_printf("%u\n", a);
}
```
Commands:
```bash
> /scratch/tc-testing/tc-apr-23/build-rv64gcv/build-llvm-linux/bin/clang -fno-strict-aliasing -march=rv64gcv -flto -O3 red.c -o red.out
> /scratch/tc-testing/tc-apr-23/build-rv64gcv/bin/qemu-riscv64 red.out
0
> /scratch/tc-testing/tc-apr-23/build-rv64gcv/build-llvm-linux/bin/clang -fno-strict-aliasing red.c -o red.out
> /scratch/tc-testing/tc-apr-23/build-rv64gcv/bin/qemu-riscv64 red.out
1
```
Reduced LLVM IR:
```llvm ir
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "riscv64-unknown-linux-gnu"
@.str = constant [4 x i8] c"%u\0A\00"
define i32 @main(ptr %a, ptr %f, i16 %0) #0 {
for.cond6.preheader.us.preheader:
%1 = load i16, ptr %f, align 2
%conv.us = zext i16 %1 to i32
%conv13.us = sext i16 %0 to i32
%cmp14.us.not = icmp ule i32 %conv.us, %conv13.us
%conv.us.1 = zext i16 0 to i32
%conv13.us.1 = sext i16 0 to i32
%cmp14.us.1 = icmp ule i32 %conv.us.1, %conv13.us.1
%.not5.not7.not10.not13 = and i1 %cmp14.us.not, %cmp14.us.1
%conv.us.2 = zext i16 0 to i32
%conv13.us.2 = sext i16 0 to i32
%cmp14.us.2 = icmp ule i32 %conv.us.2, %conv13.us.2
%conv.us.3 = zext i16 0 to i32
%conv13.us.3 = sext i16 0 to i32
%cmp14.us.3 = icmp ule i32 %conv.us.3, %conv13.us.3
%2 = and i1 %.not5.not7.not10.not13, %cmp14.us.3
%narrow = and i1 %2, %cmp14.us.2
%cond.us.3 = zext i1 %narrow to i32
%call = tail call i32 (ptr, ...) @printf(ptr @.str, i32 %cond.us.3)
ret i32 0
}
declare i32 @printf(ptr, ...)
attributes #0 = { "target-features"="+64bit,+a,+v" }
```
Commands:
```
/scratch/tc-testing/tc-apr-23/build-rv64gcv/build-llvm-linux/bin/clang $1 -o baseline.out
/scratch/tc-testing/tc-apr-23/build-rv64gcv/build-llvm-linux/bin/opt -passes=slp-vectorizer $1 > opt.bc
/scratch/tc-testing/tc-apr-23/build-rv64gcv/build-llvm-linux/bin/clang opt.bc -o opt.out
/scratch/tc-testing/tc-apr-23/build-rv64gcv/bin/qemu-riscv64 opt.out
0
/scratch/tc-testing/tc-apr-23/build-rv64gcv/bin/qemu-riscv64 baseline.out
1
```
Found via fuzzer
@alexey-bataev
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89987] Assertion `I.isArrayAllocation()' failed with SVE-AES
Issue
89987
Summary
Assertion `I.isArrayAllocation()' failed with SVE-AES
Labels
new issue
Assignees
Reporter
same-denik
The following program triggers the compiler crash with the error "fatal error: error in backend: Invalid size request on a scalable vector.":
```
$ cat test.ii
typedef __SVInt64_t s_t;
void bar(s_t a);
void foo() {
s_t a;
bar(a);
}
$ clang -cc1 -triple aarch64-grtev4-linux-gnu -emit-obj -fsanitize=local-bounds -target-feature +sve2-aes test.ii
fatal error: error in backend: Invalid size request on a scalable vector.
```
Backtrace:
```
clang: /home/denik/storage/llvm-project/llvm/lib/Analysis/MemoryBuiltins.cpp:1142: llvm::SizeOffsetValue llvm::ObjectSizeOffsetEvaluator::visitAllocaInst(llvm::AllocaInst&): Assertion `I.isArrayAllocation()' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /home/denik/storage/llvm_build/bin/clang -cc1 -triple aarch64-grtev4-linux-gnu -emit-obj -fsanitize=local-bounds -target-feature +sve2-aes test.ii
1. parser at end of file
2. Optimizer
#0 0x7fb376068e81 __interceptor_backtrace.part.0 /build/gcc-13-Hz7jz6/gcc-13-13.2.0/build/x86_64-linux-gnu/libsanitizer/asan/../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4434:28
#1 0x55ea2bc465c9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/denik/storage/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22
#2 0x55ea2bc46928 PrintStackTraceSignalHandler(void*) /home/denik/storage/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
#3 0x55ea2bc3ce7c llvm::sys::RunSignalHandlers() /home/denik/storage/llvm-project/llvm/lib/Support/Signals.cpp:105:20
#4 0x55ea2bc3f55d SignalHandler(int) /home/denik/storage/llvm-project/llvm/lib/Support/Unix/Signals.inc:403:31
#5 0x7fb37597b510 (/lib/x86_64-linux-gnu/libc.so.6+0x3c510)
#6 0x7fb3759c916c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#7 0x7fb37597b472 raise ./signal/../sysdeps/posix/raise.c:27:6
#8 0x7fb3759654b2 abort ./stdlib/abort.c:81:7
#9 0x7fb3759653d5 _nl_load_domain ./intl/loadmsgcat.c:1177:9
#10 0x7fb3759743a2 (/lib/x86_64-linux-gnu/libc.so.6+0x353a2)
#11 0x55ea27ed6b61 llvm::ObjectSizeOffsetEvaluator::visitAllocaInst(llvm::AllocaInst&) /home/denik/storage/llvm-project/llvm/lib/Analysis/MemoryBuiltins.cpp:1148:7
#12 0x55ea27ef6f0c llvm::InstVisitor::visitAlloca(llvm::AllocaInst&) /home/denik/storage/llvm-project/llvm/include/llvm/IR/Instruction.def:171:1
#13 0x55ea27ef6f0c llvm::InstVisitor::visit(llvm::Instruction&) /home/denik/storage/llvm-project/llvm/include/llvm/IR/Instruction.def:171:1
#14 0x55ea27ee615f llvm::ObjectSizeOffsetEvaluator::compute_(llvm::Value*) /home/denik/storage/llvm-project/llvm/lib/Analysis/MemoryBuiltins.cpp:1117:19
#15 0x55ea27eeac75 llvm::ObjectSizeOffsetEvaluator::compute(llvm::Value*) /home/denik/storage/llvm-project/llvm/lib/Analysis/MemoryBuiltins.cpp:1061:36
#16 0x55ea3176b19a getBoundsCheckCond(llvm::Value*, llvm::Value*, llvm::DataLayout const&, llvm::TargetLibraryInfo&, llvm::ObjectSizeOffsetEvaluator&, llvm::IRBuilder&, llvm::ScalarEvolution&) /home/denik/storage/llvm-project/llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp:64:51
#17 0x55ea31772ae4 addBoundsChecking(llvm::Function&, llvm::TargetLibraryInfo&, llvm::ScalarEvolution&) /home/denik/storage/llvm-project/llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp:161:32
#18 0x55ea317756e5 llvm::BoundsCheckingPass::run(llvm::Function&, llvm::AnalysisManager&) /home/denik/storage/llvm-project/llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp:229:3
#19 0x55ea2c6578c7 llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) /hom
e/denik/storage/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3
#20 0x55ea2a4ba20c llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) /home/denik/storage/llvm-project/llvm/include/llvm/IR/PassManager.h:228:20
#21 0x55ea21ad9651 llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) /home/denik/storage/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:0
#22 0x55ea2a49b0ba llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) /home/denik/storage/llvm-project/llvm/lib/IR/PassManager.cpp:128:19
#23 0x55ea21adafcb llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) /home/denik/storage/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:0
#24 0x55ea2a4b6bae llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&)
[llvm-bugs] [Bug 89986] Do you still need commit access?
Issue 89986 Summary Do you still need commit access? Labels infrastructure:commit-access Assignees Reporter tstellar ### TLDR: If you want to retain your commit access, please comment on this issue. Otherwise, you can unsubscribe from this issue and ignore it. Commit access is not required to contribute to the project. You can still create Pull Requests without commit access. @steven-wan-yu @pestctrl @mscuttari @atmnpatel @rtenneti-google @kuzkry @markschimmel @akshaykhadse @HLJ2009 @AlexisPerry @TaWeiTu @ksyx @graham-yiu @morehouse @tzolnai @mcinally @yavtuk @Kmeakin @ibricchi @cddouma LLVM has a policy of downgrading write access to its repositories for accounts with long term inactivity. This is done because inactive accounts with high levels of access tend to be at increased risk of compromise and this is one tactic that the project employs to guard itself from malicious actors. Note that write access is not required to contribute to the project. You can still submit pull requests and have someone else merge them. Our project policy is to ping anyone with less than five 'interactions' with the repositories over a 12 month period to see if they still need commit access. An 'interaction' and be any one of: * Pushing a commit. * Merging a pull request (either their own or someone else’s). * Commenting on a PR. If you want to retain your commit access, please post a comment on this issue. If you do not want to keep your commit access, you can just ignore this issue. If you have not responded in 6 weeks, then you will move moved from the 'write' role within the project to the 'triage' role. The 'triage' role is still a privileged role and will allow you to do the following: * Review Pull Requests. * Comment on issues. * Apply/dismiss labels. * Close, reopen, and assign all issues and pull requests. * Apply milestones. * Mark duplicate issues and pull requests. * Request pull request reviews. * Hide anyone’s comments. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89983] incorrect warning that a static member function parameter shadows an inherited member variable
Issue
89983
Summary
incorrect warning that a static member function parameter shadows an inherited member variable
Labels
new issue
Assignees
Reporter
torsten48
`class base {
public:
int i;
};
class test : public base {
public:
int j;
static int fn1(int j) { return --j; }
static int fn2(int i) { return ++i; }
};
int main(void)
{}
`
produces the following warning (tested with clang 16, 17 and 18.1.0):
`:11:24: warning: parameter 'i' shadows member inherited from type 'base' [-Wshadow-field]
static int fn2(int i) { return ++i; }
^
:3:9: note: declared here
int i;
^`
Correctly, there is no warning regarding the class member j, but but mistakenly for the inherited i.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89971] AMDGPU inline assembly with s constraint incorrectly emits VGPR use
Issue
89971
Summary
AMDGPU inline assembly with s constraint incorrectly emits VGPR use
Labels
backend:AMDGPU
Assignees
Reporter
arsenm
https://godbolt.org/z/Yonee4P1G
```
define hidden i32 @test(i32 noundef %mask) local_unnamed_addr #0 {
entry:
%tobool = icmp ne i32 %mask, 0
%0 = tail call i64 @llvm.amdgcn.ballot.i64(i1 %tobool)
%cmp = icmp eq i64 %0, 0
%conv = zext i1 %cmp to i32
%1 = tail call i32 asm sideeffect "s_mov_b32 $0, $1", "=s,s"(i32 %conv) #2
ret i32 %1
}
```
This is incorrectly emitting a VGPR for the use operand `s_mov_b32 s0, v0`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89968] ER: Add diagnostic to flag using "%P" specifier with Objective-C pointers
Issue
89968
Summary
ER: Add diagnostic to flag using "%P" specifier with Objective-C pointers
Labels
new issue
Assignees
Reporter
jaredgrubb
Darwin has an extension on the printf format-specifiers for "%P", which dumps the bytes at a pointer (in contrast to "%p" which dumps a pointer's value itself) and is allowed in "OS Log" contexts.
It's easy to misuse this, for example:
```
NSUUID *uuid = ...;
os_log(..., "%{uuid_t}.16P", uuid);
```
This dumps the ObjC class data (eg, the _is-a_ pointer) -- not the UUID represented by the object.
It'd be nice if the compiler had a warning that could flag this misuse, which seems to always (IMO) be a bug.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89965] potentially incorrect Emacs marker in headers
Issue 89965 Summary potentially incorrect Emacs marker in headers Labels new issue Assignees Reporter firewave According to https://llvm.org/docs/CodingStandards.html#file-headers the way to tell Emacs that a file is C++ is `-*- C++ -*-`. But while implementing and testing support for this I ran into a few files which appears to have mistakes in that. Those markers are looking like this: ``` -*- C++ --*- -*- C++ ---*- -*- C++ --*- -*- C++ ---*- -*- C++ *- -*- C++ -*- -*- C++ --*- -*- C++/-*- ``` Since it is really hard to find a proper specification for this I cannot tell if these would actually be valid. But since no other files in the `/usr/include` of my distro have such markers I assume they are wrong. Here is the list of affected files. ``` /usr/include/clang/Analysis/Analyses/LiveVariables.h /usr/include/clang/Analysis/Analyses/ReachableCode.h /usr/include/clang/Analysis/Analyses/ThreadSafetyLogical.h /usr/include/clang/Tooling/AllTUsExecution.h /usr/include/clang/Tooling/Execution.h /usr/include/clang/Tooling/StandaloneExecution.h /usr/include/clang/Tooling/Syntax/Mutations.h /usr/include/llvm/Analysis/InlineAdvisor.h /usr/include/llvm/Analysis/InlineOrder.h /usr/include/llvm/Analysis/ReplayInlineAdvisor.h /usr/include/llvm/BinaryFormat/DXContainer.h /usr/include/llvm/BinaryFormat/XCOFF.h /usr/include/llvm/MC/MCDXContainerWriter.h /usr/include/llvm/Remarks/RemarkFormat.h /usr/include/llvm/Remarks/Remark.h /usr/include/llvm/Remarks/RemarkLinker.h /usr/include/llvm/Remarks/RemarkParser.h /usr/include/llvm/Remarks/RemarkStringTable.h /usr/include/llvm/Transforms/Utils/MemoryOpRemark.h ``` While at it, it might also make sense to check if there are files which are completely lacking the marker. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89959] Assertion in Scalar Evolution when running IRCE
Issue
89959
Summary
Assertion in Scalar Evolution when running IRCE
Labels
new issue
Assignees
Reporter
gbaraldi
The following IR crashes with
```llvm
define void @foo() {
top:
br label %L3
L3: ; preds = %L13, %top
%value_phi = phi ptr [ null, %top ], [ %0, %L13 ]
%0 = getelementptr i8, ptr %value_phi, i64 8
%.not = icmp ule ptr %value_phi, null
br i1 %.not, label %L13, label %L15
L13: ; preds = %L3
br label %L3
L15: ; preds = %L3
ret void
}
```
`opt --passes=irce`
https://godbolt.org/z/1sbvaT7r1
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89958] miscompilation due to LoopVectorize making a function vulnerable to integer divide-by-zero
Issue
89958
Summary
miscompilation due to LoopVectorize making a function vulnerable to integer divide-by-zero
Labels
miscompilation
Assignees
Reporter
regehr
https://alive2.llvm.org/ce/z/Kx2anL
this function:
```llvm
define i64 @f(i64 %0) {
br label %2
2: ; preds = %5, %1
%3 = phi i64 [ 0, %1 ], [ %6, %5 ]
%4 = icmp slt i64 %3, %0
br i1 %4, label %5, label %9
5:; preds = %2
%6 = add i64 %3, 1
%7 = udiv i64 42, %0
%8 = icmp slt i64 %3, %7
br i1 %8, label %2, label %9
9: ; preds = %5, %2
%10 = phi i64 [ 1, %2 ], [ 0, %5 ]
ret i64 %10
}
```
is getting optimized to:
```lllvm
define noundef i64 @f(i64 %0) local_unnamed_addr #0 {
%smax = tail call i64 @llvm.smax.i64(i64 %0, i64 0)
%2 = udiv i64 42, %0
%umin = tail call i64 @llvm.umin.i64(i64 %smax, i64 %2)
%min.iters.check = icmp ult i64 %umin, 4
br i1 %min.iters.check, label %scalar.ph.preheader, label %vector.ph
vector.ph: ; preds = %1
%3 = add nuw nsw i64 %umin, 1
%n.mod.vf = and i64 %3, 3
%4 = icmp eq i64 %n.mod.vf, 0
%5 = select i1 %4, i64 4, i64 %n.mod.vf
%n.vec = sub nsw i64 %3, %5
br label %vector.body
vector.body: ; preds = %vector.body, %vector.ph
%index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
%index.next = add nuw i64 %index, 4
%6 = icmp eq i64 %index.next, %n.vec
br i1 %6, label %scalar.ph.preheader, label %vector.body, !llvm.loop !0
scalar.ph.preheader: ; preds = %vector.body, %1
%.ph = phi i64 [ 0, %1 ], [ %n.vec, %vector.body ]
br label %scalar.ph
scalar.ph: ; preds = %scalar.ph.preheader, %9
%7 = phi i64 [ %10, %9 ], [ %.ph, %scalar.ph.preheader ]
%8 = icmp slt i64 %7, %0
br i1 %8, label %9, label %13
9: ; preds = %scalar.ph
%10 = add nuw nsw i64 %7, 1
%11 = udiv i64 42, %0
%12 = icmp ult i64 %7, %11
br i1 %12, label %scalar.ph, label %13, !llvm.loop !3
13: ; preds = %9, %scalar.ph
%14 = phi i64 [ 1, %scalar.ph ], [ 0, %9 ]
ret i64 %14
}
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare i64 @llvm.smax.i64(i64, i64) #1
; Function Attrs: nocallback nofree nosync nounwind speculatable willreturn memory(none)
declare i64 @llvm.umin.i64(i64, i64) #1
attributes #0 = { nofree norecurse nosync nounwind memory(none) }
attributes #1 = { nocallback nofree nosync nounwind speculatable willreturn memory(none) }
!0 = distinct !{!0, !1, !2}
!1 = !{!"llvm.loop.isvectorized", i32 1}
!2 = !{!"llvm.loop.unroll.runtime.disable"}
!3 = distinct !{!3, !2, !1}
```
the problem is that the optimized code can divide by zero even when the original code doesn't. to see this, pass 0 as an argument to `f`. I also independently verified on an x64-64 that the optimized code traps out with an FPE while the original code does not. it's LoopVectorize that's the culprit.
cc @nunoplopes @hatsunespica
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89952] [DirectX] Fix DXIL part header version encoding
Issue 89952 Summary [DirectX] Fix DXIL part header version encoding Labels backend:DirectX Assignees Reporter llvm-beanz Today we are encoding the DXIL version in the DXIL part's program header backwards. Compiling a shader targeting `lib_6_8` with DXC then disassembling it with `obj2yaml` prints: ``` DXILMajorVersion: 8 DXILMinorVersion: 1 ``` This probably means we're crossing the ordering of the fields somewhere in our handling. We also need to set the DXIL version from the triple sub-architecture. Right now during DXIL header generation we are not setting the version. See [here](https://github.com/llvm/llvm-project/blob/main/llvm/lib/MC/MCDXContainerWriter.cpp#L121) where we set the shader model version but we don't set the DXIL version. ## Acceptance Criteria * Updated obj2yaml tests verifying correct reproduction of major and minor versions. * Updated llc -> obj2yaml testing verifying correct code generation from llc. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89945] clang-include-cleaner: `` misidentified as unused
Issue
89945
Summary
clang-include-cleaner: `` misidentified as unused
Labels
new issue
Assignees
Reporter
wangtz0607
## Example
```cpp
#include
int main() {
bool b = typeid(int) != typeid(double);
return 0;
}
```
## Expected Behavior
`` should not be considered as unused.
## Actual Behavior
## Environment
```sh
clangd version 18.1.2
Features: linux
Platform: x86_64-unknown-linux-gnu
```
```sh
LLVM (http://llvm.org/):
LLVM version 18.1.2
Optimized build.
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89941] llvm::OverflowingBinaryOperator;
Issue 89941 Summary llvm::OverflowingBinaryOperator; Labels new issue Assignees Reporter AFlexeder Using llvm in combination with the alive2 toolkit resulted in a core dump. Attached is the error report llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = llvm::OverflowingBinaryOperator; From = const llvm::Instruction]: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed. #0 0x7f7e172018b0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (llvm-project/build/lib/libLLVMSupport.so.19.0git+0x2088b0) #1 0x7f7e171fe8bf llvm::sys::RunSignalHandlers() (llvm-project/build/lib/libLLVMSupport.so.19.0git+0x2058bf) #2 0x7f7e171fea15 SignalHandler(int) Signals.cpp:0:0 #3 0x7f7e16bb2520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #4 0x7f7e16c069fc __pthread_kill_implementation ./nptl/./nptl/pthread_kill.c:44:76 #5 0x7f7e16c069fc __pthread_kill_internal ./nptl/./nptl/pthread_kill.c:78:10 #6 0x7f7e16c069fc pthread_kill ./nptl/./nptl/pthread_kill.c:89:10 #7 0x7f7e16bb2476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #8 0x7f7e16b987f3 abort ./stdlib/./stdlib/abort.c:81:7 #9 0x7f7e16b9871b _nl_load_domain ./intl/./intl/loadmsgcat.c:1177:9 #10 0x7f7e16ba9e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96) #11 0x7f7e175cd9bb (llvm-project/build/lib/libLLVMCore.so.19.0git+0x29a9bb) #12 0x7f7e196f666d (anonymous namespace)::llvm2alive_::visitCastInst(llvm::CastInst&) llvm2alive.cpp:0:0 #13 0x7f7e196ff1e8 llvm::InstVisitor<(anonymous namespace)::llvm2alive_, std::unique_ptr > >::visit(llvm::Instruction&) llvm2alive.cpp:0:0 #14 0x7f7e197027c3 (anonymous namespace)::llvm2alive_::run() llvm2alive.cpp:0:0 #15 0x7f7e19703b61 llvm_util::llvm2alive(llvm::Function&, llvm::TargetLibraryInfo const&, bool, std::vector >, std::allocator > > > const&) (alive2/build/alive-tv+0x56b61) #16 0x7f7e196eac32 (anonymous namespace)::verify(llvm::Function&, llvm::Function&, llvm::TargetLibraryInfoWrapperPass&, smt::smt_initializer&, std::ostream&, bool, bool) compare.cpp:0:0 #17 0x7f7e196ee294 llvm_util::Verifier::compareFunctions(llvm::Function&, llvm::Function&) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89940] Generic Operation builder does not set up properties
Issue
89940
Summary
Generic Operation builder does not set up properties
Labels
new issue
Assignees
Reporter
jschj
We use some of the auto-generated “generic” builders with return type inference for some our operations in our code base. They roughly look like this:
```
void MyOp::build(::mlir::OpBuilder , ::mlir::OperationState , ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes) {
assert(operands.size() >= 1u && "mismatched number of parameters");
odsState.addOperands(operands);
odsState.addAttributes(attributes);
::llvm::SmallVector<::mlir::Type, 2> inferredReturnTypes;
if (::mlir::succeeded(MyOp::inferReturnTypes(odsBuilder.getContext(),
odsState.location, operands,
odsState.attributes.getDictionary(odsState.getContext()),
odsState.getRawProperties(),
odsState.regions, inferredReturnTypes))) {
assert(inferredReturnTypes.size() == 1u && "mismatched number of return types");
odsState.addTypes(inferredReturnTypes);
} else {
::llvm::report_fatal_error("Failed to infer result type(s).");
}
}
```
The problem is that at no point the properties are set up. The other builders (the ones where the individual operands are provided) do eventually call `odsState.getOrAddProperties();`. This poses a problem in our case since we rely on operandSegmentSizes (which is a property) to be correctly set up. This issue is happening with the release version of LLVM18.
To reproduce someone might simply look at the generated "generic" builders of any operation with properties.
[Discourse link](https://discourse.llvm.org/t/generic-operation-builder-does-not-set-up-properties/78552)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89937] x86 backend generates unoptimal loop alignment for Skylake and Sandy Bridge processors
Issue 89937 Summary x86 backend generates unoptimal loop alignment for Skylake and Sandy Bridge processors Labels new issue Assignees Reporter lucic71 When compiling the following LLVM IR file: [test.ll](https://drive.google.com/file/d/1s_ERe3hP-OmoMrVrFELLkYAdfy2MPbWA/view?usp=sharing) we observed a considerable performance gain by modifying the loop alignment generated by LLVM inside the function called `test`. The default alignment generated by LLVM is 16 bits, as shown in [test.S](https://drive.google.com/file/d/1qRDBV9KHpCZaogN7QI09cDMJDfkwWYI_/view?usp=sharing) at line 34. On a Skylake machine we got the following performance with the alignment generated by LLVM: ``` Elapsed time: 2.512872 seconds ``` By changing the `p2align 4` at line 34 inside [test.S](https://drive.google.com/file/d/1qRDBV9KHpCZaogN7QI09cDMJDfkwWYI_/view?usp=sharing) to a `p2align 5`, we got: ``` Elapsed time: 2.196517 seconds ``` That's a performance improvement of around 12%! On another machine, this time Sandy Bridge, we saw the following numbers: 4.3s for p2align4 and 2.5s for p2align5. The steps for reproducing the issue are: ``` $ llc -o test.S test.ll $ clang -o test test.S $ ./test Elapsed time: 2.512872 seconds $ # in test.S at line 34 change `p2align 4` with `p2align 5` $ clang -o test test.S $ ./test Elapsed time: 2.196517 seconds $ clang --version 16.0.6 ``` This is how the assembly looks like for the `test` function with p2align4: ```asm 11b0 : 11b0: 48 85 f6test %rsi,%rsi 11b3: 7e 13 jle11c8 11b5: 48 8d 46 ff lea-0x1(%rsi),%rax 11b9: 39 54 b7 fc cmp %edx,-0x4(%rdi,%rsi,4) 11bd: 48 89 c6mov %rax,%rsi 11c0: 75 ee jne11b0 11c2: b8 01 00 00 00 mov$0x1,%eax 11c7: c3 ret 11c8: b8 ff ff ff ff mov $0x,%eax 11cd: c3 ret ``` And this is how it looks with p2align5: ```asm 11d0 : 11d0: 66 2e 0f 1f 84 00 00cs nopw 0x0(%rax,%rax,1) 11d7: 00 00 00 11da: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 11e0: 48 85 f6test %rsi,%rsi 11e3: 7e 13 jle11f8 11e5: 48 8d 46 ff lea -0x1(%rsi),%rax 11e9: 39 54 b7 fc cmp %edx,-0x4(%rdi,%rsi,4) 11ed: 48 89 c6mov %rax,%rsi 11f0: 75 ee jne11e0 11f2: b8 01 00 00 00 mov$0x1,%eax 11f7: c3 ret 11f8: b8 ff ff ff ff mov$0x,%eax 11fd: c3 ret ``` Notice that the loop size is 18 in both cases (starting from the `test` instruction and ending at the `jne` instruction), the only thing that differs is the start address of the loop. For p2align4 the start address is 11b0 (aligned to 16 bits) and for p2align5 the start address is 11e0 (aligned to 32 bits). There was a [similar issue](https://lists.llvm.org/pipermail/llvm-dev/2021-January/148177.html) raised a few years ago where Maxim Kazantsev thought that this workload is bound to decoding so we decided to gather the same perf numbers as he did: ``` p2align4: 3,181,514,079 idq.all_dsb_cycles_4_uops ( +- 0.21% ) (29.99%) 6,271,689,140 idq.all_dsb_cycles_any_uops ( +- 0.23% ) (30.08%) 6,306,733,259 idq.dsb_cycles ( +- 0.22% ) (30.08%) 16,393,899,425 idq.dsb_uops ( +- 0.12% ) (30.13%) ``` ``` p2align5: 3,194,348,681 idq.all_dsb_cycles_4_uops ( +- 0.18% ) (29.93%) 3,367,347,174 idq.all_dsb_cycles_any_uops ( +- 0.15% ) (30.03%) 3,361,525,370 idq.dsb_cycles ( +- 0.14% ) (30.13%) 16,302,023,646 idq.dsb_uops ( +- 0.12% ) (30.15%) ``` Notice that p2align5 is delivering more 4upos batches than p2align4 and the number of cycles spent in DSB decreases for p2align5. In the linked issue, Maxim proposed some interesting solutions for solving this problem: ``` Align loops by 32 if: * They are innermost; * Size of loop mod 32 is between 16 and 31 (only in this case alignment by 32 will strictly reduce the number of 32 window crossings by 1); * (Optional) The loop is small, e.g. less than 32 bytes; * (Optional) We could make even sharper checks trying to ensure that all other conditions of DSB max utilization are met (may be very complex!) ``` cc: @nunoplopes ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89935] Clangs' frontend failed because file to compile had been changed during compilation
Issue 89935 Summary Clangs' frontend failed because file to compile had been changed during compilation Labels new issue Assignees Reporter ii-sc To whom it may concern: I was working on backend optimization and during a build process I made a change in file which was being compiled. ``` clang++: error: unable to execute command: Segmentation fault (core dumped) clang++: note: diagnostic msg: Error generating preprocessed source(s). ninja: build stopped: subcommand failed. ``` Full stack trace and warnings that have been emitted only during this unsuccessful run are in the attached file. [trace.txt](https://github.com/llvm/llvm-project/files/15095845/trace.txt) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89926] mlir-opt --tosa-to-linalg-pipeline fails in validation: element type 'f32' is not legal
Issue
89926
Summary
mlir-opt --tosa-to-linalg-pipeline fails in validation: element type 'f32' is not legal
Labels
new issue
Assignees
Reporter
PerMildner
It seems `mlir-opt --tosa-to-linalg-pipeline` unconditionally uses the Basic Inference profile, and therefore only allows integer types.
The help-text for `--tosa-to-linalg-pipeline` says
> The default pipeline for converting TOSA operators to the equivalent operations using the tensor operations in LinAlg as well as LinAlg named operations.
so I would have assumed it should be usable also for floating point tensors.
I could not find any tests using `--tosa-to-linalg-pipeline` except tests that are supposed to fail. Other tests seems build a stripped down version of `--tosa-to-linalg-pipeline` using explicit `--pass-pipeline`.
The symptom is:
```
$ cat ../bad_tosa.mlir
module attributes {llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", llvm.target_triple = "x86_64-unknown-linux-gnu"} {
func.func @main_graph() -> (tensor<1xf32>) {
%0 = "tosa.const"() <{value = dense<0.00e+00> : tensor<1xf32>}> : () -> tensor<1xf32>
return %0 : tensor<1xf32>
}
}
$ build/bin/mlir-opt --tosa-to-linalg-pipeline ../bad_tosa.mlir
../bad_tosa.mlir:3:10: error: 'tosa.const' op is not profile-aligned: element type 'f32' is not legal
%0 = "tosa.const"() <{value = dense<0.00e+00> : tensor<1xf32>}> : () -> tensor<1xf32>
^
../bad_tosa.mlir:3:10: note: see current operation: %0 = "tosa.const"() <{value = dense<0.00e+00> : tensor<1xf32>}> : () -> tensor<1xf32>
../bad_tosa.mlir:4:5: error: 'func.return' op is not profile-aligned: element type 'f32' is not legal
return %0 : tensor<1xf32>
^
../bad_tosa.mlir:4:5: note: see current operation: "func.return"(%0) : (tensor<1xf32>) -> ()
```
Commit 2bcbe40f8a1c6cc9a256711261d8aa8fde50f7b3.
I have attached a full transcript.
[bad_tosa.txt](https://github.com/llvm/llvm-project/files/15094963/bad_tosa.txt)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89921] clang-tidy wrongly reports bugprone-macro-parentheses on non-arguments
Issue
89921
Summary
clang-tidy wrongly reports bugprone-macro-parentheses on non-arguments
Labels
clang-tidy
Assignees
Reporter
j-jorge
Given the following code :
```c++
#include
#ifndef FOO
#define FOO a-b
#endif
int main()
{
#define STR0(x) #x
#define STR(x) STR0(x)
printf("%s\n", STR(FOO));
}
```
A run of `clang-tidy --checks=bugprone-macro-parentheses` will complain about the need of replacing `a` and `b` by `(a)` and `(b)` ([Compiler Explorer demo](https://godbolt.org/z/ETdvP75av)) :
```
warning: macro replacement list should be enclosed in parentheses [bugprone-macro-parentheses]
[:4:14: warning: macro replacement list should be enclosed in parentheses [bugprone-macro-parentheses]](_javascript_:;)
4 | #define FOO a-b
```
I believe this is a false positive. Since none of `a` or `b` are arguments of the macro they should not be considered by the check.
My actual use case is similar to this code. I have a preprocessor definition coming from the command line (`-DFOO=some-string-with-dashes`) which I turn into a C-string in the code via the `STR()` macro. The workaround is to drop the `STR` macro and put the quotes in the command-line, but I would have preferred no workaround :)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89916] clang-format AlignTrailingComments wrong with cyrilic characters
Issue
89916
Summary
clang-format AlignTrailingComments wrong with cyrilic characters
Labels
clang-format
Assignees
Reporter
kmoski
.clang-format file:
```
AlignTrailingComments:
Kind: Always
ColumnLimit: 80
```
expect code utf8:
```c
struct foo {
int i; ///< ii
int b; ///< ыыы
int c; ///<
};
```
actual code utf8:
```c
struct foo {
int i; ///< ii
int b; ///< ыыы
int c; ///<
};
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89914] [abi] mangled name for constrained template is not demangled by llvm-cxxfilt
Issue
89914
Summary
[abi] mangled name for constrained template is not demangled by llvm-cxxfilt
Labels
clang,
ABI
Assignees
Reporter
hokein
Example:
```
template
concept True = true;
template
struct Foo {
template U>
void method(U t);
};
void s() {
Foo k;
k.method(1);
}
```
Clang generates mangled name `_ZN3FooIiE6methodITk4TrueIT_EiEEvS3_` for the template specialization `Foo::method`. However this mangled name can not be demangled by the official tool `llvm-cxxfilt`.
It looks like something wrong with the constrain `True` part.
PS. gcc trunk generates a different name `_ZN3FooIiE6methodIiEEvT_`, which can be demangled, but it doesn't contain the constraint.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89912] Missed optimization: Redundant array assignment
Issue
89912
Summary
Missed optimization: Redundant array assignment
Labels
new issue
Assignees
Reporter
ZY546
The following reduced code makes the same assignment to array `a` twice, the second time being redundant.
https://godbolt.org/z/8Kods3soK
```cpp
int a[1024];
int b[1024];
void func()
{
for (int i = 0; i < 1024; i+=1) {
a[i] = b[i] * 2;
}
for (int i = 0; i < 1024; i+=1) {
a[i] = b[i] * 2;
}
}
```
Clang:
```asm
func: # @func
xor edx, edx
lea rax, [rip + b]
lea rcx, [rip + a]
.LBB0_1:# =>This Inner Loop Header: Depth=1
movdqa xmm0, xmmword ptr [rax + 4*rdx]
movdqa xmm1, xmmword ptr [rax + 4*rdx + 16]
movdqa xmm2, xmmword ptr [rax + 4*rdx + 32]
movdqa xmm3, xmmword ptr [rax + 4*rdx + 48]
paddd xmm0, xmm0
paddd xmm1, xmm1
movdqa xmmword ptr [rcx + 4*rdx], xmm0
movdqa xmmword ptr [rcx + 4*rdx + 16], xmm1
paddd xmm2, xmm2
paddd xmm3, xmm3
movdqa xmmword ptr [rcx + 4*rdx + 32], xmm2
movdqa xmmword ptr [rcx + 4*rdx + 48], xmm3
add rdx, 16
cmp rdx, 1024
jne .LBB0_1
xor edx, edx
.LBB0_3:# =>This Inner Loop Header: Depth=1
movdqa xmm0, xmmword ptr [rax + 4*rdx]
movdqa xmm1, xmmword ptr [rax + 4*rdx + 16]
movdqa xmm2, xmmword ptr [rax + 4*rdx + 32]
movdqa xmm3, xmmword ptr [rax + 4*rdx + 48]
paddd xmm0, xmm0
paddd xmm1, xmm1
movdqa xmmword ptr [rcx + 4*rdx], xmm0
movdqa xmmword ptr [rcx + 4*rdx + 16], xmm1
paddd xmm2, xmm2
paddd xmm3, xmm3
movdqa xmmword ptr [rcx + 4*rdx + 32], xmm2
movdqa xmmword ptr [rcx + 4*rdx + 48], xmm3
add rdx, 16
cmp rdx, 1024
jne .LBB0_3
ret
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89909] Implementing friend operator with two exclusive requires clauses but same name of requirement causes "error: redefinition of 'operator<<'"
Issue 89909 Summary Implementing friend operator with two exclusive requires clauses but same name of requirement causes "error: redefinition of 'operator<<'" Labels new issue Assignees Reporter gsamatt This does not compile with clang 18 but it does with clang 17: https://godbolt.org/z/orMfTfxMd This would compile with both compiler as it uses a different name for the requirement: https://godbolt.org/z/Mjxq54abb ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89898] Ranges pipe syntax broken after commit #c1086532d4d5 when using std module.
Issue
89898
Summary
Ranges pipe syntax broken after commit #c1086532d4d5 when using std module.
Labels
new issue
Assignees
Reporter
stripe2933
The following code
```cpp
#include
#include
int main(){
using namespace std::string_view_literals;
std::println("{}", "abcde"sv | std::views::transform([](char c) { return c - 'a'; }));
}
```
works correctly ([godbolt link](https://godbolt.org/z/T4vYssK8z)) in Clang trunk. However, when changing the header inclusion to `import std;`, then the code will emit error:
```
main.cpp:5:34: error: invalid operands to binary _expression_ ('basic_string_view' and '__range_adaptor_closure_t<__bind_back_t<__fn, tuple<(lambda at main.cpp:5:58)>>>' (aka 'std::__1::ranges::__range_adaptor_closure_t>>'))
5 | std::println("{}", "abcde"sv | std::views::transform([](char c) { return c - 'a'; }));
|~ ^ ~
llvm-project/build/include/c++/v1/cstddef:73:45: note: candidate function not viable: no known conversion from 'basic_string_view' to 'byte' for 1st argument
73 | _LIBCPP_HIDE_FROM_ABI inline constexpr byte operator|(byte __lhs, byte __rhs) noexcept {
| ^ ~~
llvm-project/build/include/c++/v1/__charconv/chars_format.h:34:53: note: candidate function not viable: no known conversion from 'basic_string_view' to 'chars_format' for 1st argument
34 | inline _LIBCPP_HIDE_FROM_ABI constexpr chars_format operator|(chars_format __x, chars_format __y) {
| ^
llvm-project/build/include/c++/v1/future:433:55: note: candidate function not viable: no known conversion from 'basic_string_view' to 'launch' for 1st argument
433 | inline _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR launch operator|(launch __x, launch __y) {
| ^ ~~
llvm-project/build/include/c++/v1/bitset:929:1: note: candidate template ignored: could not match 'bitset' against 'basic_string_view'
929 | operator|(const bitset<_Size>& __x, const bitset<_Size>& __y) _NOEXCEPT {
| ^
llvm-project/build/include/c++/v1/valarray:2858:1: note: candidate template ignored: requirement '__is_val_expr>>::value' was not satisfied [with _Expr1 = basic_string_view, _Expr2 = __range_adaptor_closure_t<__bind_back_t<__fn, tuple<(lambda at main.cpp:5:58)>>>]
2858 | operator|(const _Expr1& __x, const _Expr2& __y) {
| ^
llvm-project/build/include/c++/v1/valarray:2867:5: note: candidate template ignored: requirement '__is_val_expr>>::value' was not satisfied [with _Expr = basic_string_view]
2867 | operator|(const _Expr& __x, const typename _Expr::value_type& __y) {
| ^
llvm-project/build/include/c++/v1/valarray:2876:5: note: candidate template ignored: requirement '__is_val_expr>>>::value' was not satisfied [with _Expr = __range_adaptor_closure_t<__bind_back_t<__fn, tuple<(lambda at main.cpp:5:58)>>>]
2876 | operator|(const typename _Expr::value_type& __x, const _Expr& __y) {
| ^
1 error generated.
```
Compiler: Clang 18.1.4, Libc++: trunk.
I followed the standard library module instruction documented in [libc++ document](https://libcxx.llvm.org/Modules.html#using-in-external-projects).
I noticed that the commits before `c1086532d4d5`, which corresponds to the PR #89148 does not print this error. It seems that the PR is problem.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89892] Opt: unknown pass name ‘hello’
Issue 89892 Summary Opt: unknown pass name ‘hello’ Labels new issue Assignees Reporter gihyeonjeon Hi. I am studying the contents of [https://llvm.org/docs/WritingAnLLVMPass.html 1](https://llvm.org/docs/WritingAnLLVMPass.html). When I enter ‘gmake’ in a build folder and then input ``` opt -load lib/LLVMHello.so -p=hello /dev/null ``` an error occurs stating ``` opt: unknown pass name 'hello' ``` I don’t understand what ‘legacy’ means, but I saw an answer suggesting to remove the load option, which I did, but the same problem still occurs. When I enter ``` opt -load -p=helloworld /dev/null ``` the output ‘main’ appears, but I have never created a pass called ‘helloworld’; I want to use a pass called ‘hello’. I am curious about what the problem is and how it can be solved. I got the reply from the question that I have asked on llvm. He said that I have to use another command. ``` opt -load-pass-plugin lib/LLVMHello.so -passes=hello-world ``` But the new command does not work properly. The following warning message appears. ``` bash: syntax error near unexpected token `newline' ``` I suspect that the problem occurs because of the <>. After modifying the command as follows and entering it, a bug occurred. The output sentence is as follows. ``` Failed to load passes from 'lib/LLVMHello.so'. Request ignored. Expected must be checked before access or destruction. Unchecked Expected contained error: Plugin entry point not found in 'lib/LLVMHello.so'. Is this a legacy plugin?PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: opt -load-pass-plugin lib/LLVMHello.so -passes=hello hello.bc #0 0x6443107a83f6 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/lib/Support/Unix/Signals.inc:602:22 #1 0x6443107a87d5 PrintStackTraceSignalHandler(void*) /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/lib/Support/Unix/Signals.inc:675:1 #2 0x6443107a5e99 llvm::sys::RunSignalHandlers() /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/lib/Support/Signals.cpp:104:20 #3 0x6443107a7d0e SignalHandler(int) /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/lib/Support/Unix/Signals.inc:413:1 #4 0x769d87042520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x769d870969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #6 0x769d870969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #7 0x769d870969fc pthread_kill ./nptl/pthread_kill.c:89:10 #8 0x769d87042476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #9 0x769d870287f3 abort ./stdlib/abort.c:81:7 #10 0x64430cabe5f4 llvm::SmallVectorTemplateBase::mallocForGrow(unsigned long, unsigned long&) /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/include/llvm/ADT/SmallVector.h:444:4 #11 0x64430cab93f7 llvm::Expected::assertIsChecked() const /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/include/llvm/Support/Error.h:714:3 #12 0x64430cab3280 llvm::Expected::~Expected() /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/include/llvm/Support/Error.h:550:10 #13 0x64430caa50e0 main::'lambda'(std::__cxx11::basic_string, std::allocator> const&)::operator()(std::__cxx11::basic_string, std::allocator> const&) const /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/tools/opt/opt.cpp:469:3 #14 0x64430caa827d void std::__invoke_impl, std::allocator> const&)&, std::__cxx11::basic_string, std::allocator> const&>(std::__invoke_other, main::'lambda'(std::__cxx11::basic_string, std::allocator> const&)&, std::__cxx11::basic_string, std::allocator> const&) /usr/include/c++/11/bits/invoke.h:61:67 #15 0x64430caa7fa1 std::enable_if, std::allocator> const&)&, std::__cxx11::basic_string, std::allocator> const&>, void>::type std::__invoke_r, std::allocator> const&)&, std::__cxx11::basic_string, std::allocator> const&>(main::'lambda'(std::__cxx11::basic_string, std::allocator> const&)&, std::__cxx11::basic_string, std::allocator> const&) /usr/include/c++/11/bits/invoke.h:117:5 #16 0x64430caa7cb9 std::_Function_handler, std::allocator> const&), main::'lambda'(std::__cxx11::basic_string, std::allocator> const&)>::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string, std::allocator> const&) /usr/include/c++/11/bits/std_function.h:291:44 #17 0x64430cab9f99 std::function, std::allocator> const&)>::operator()(std::__cxx11::basic_string, std::allocator> const&) const /usr/include/c++/11/bits/std_function.h:590:66 #18 0x64430cac6130 llvm::cl::list, std::allocator>, bool, llvm::cl::parser, std::allocator>>>::handleOccurrence(unsigned int, llvm::StringRef, llvm::StringRef) /home/ghjeon/llvm-project-llvmorg-17.0.6/llvm/include/llvm/Support/CommandLine.h:1670:12 #19 0x6443106b0ed2
[llvm-bugs] [Bug 89891] `std::lock_guard` is unavailable when `_LIBCPP_HAS_NO_THREADS` is set
Issue 89891 Summary `std::lock_guard` is unavailable when `_LIBCPP_HAS_NO_THREADS` is set Labels libc++ Assignees Reporter petrhosek When `_LIBCPP_HAS_NO_THREADS` is set,`std::lock_guard` becomes unavailable: https://github.com/llvm/llvm-project/blob/662ef8604268b207910225ecca90daf30a46720b/libcxx/include/__mutex/lock_guard.h#L19-L51 `std::lock_guard` takes mutex implementation as a template argument, so even if the platform doesn't support standard threading API, users may still want to use it with their own custom mutex implementation which is common on baremetal platforms. This is related to issue https://github.com/llvm/llvm-project/issues/84879. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89888] Flang driver compiler options request
Issue 89888 Summary Flang driver compiler options request Labels flang:driver Assignees Reporter jeffhammond The Flang and Clang drivers are separate but many Clang flags make sense for Flang, because they are not language specific. Here is a list of flags that Flang should support. As these are documented on https://clang.llvm.org/docs/ClangCommandLineReference.html, I will only list the option, not what it does. # currently known to be blocking, e.g. in Spack and CMake use cases - [ ] -w, --no-warnings - [ ] -mtune, -march, -mcpu - [ ] -Qunused-arguments # not known to be blockers but things I use regularly - [ ] -Wl and -Xlinker - [ ] -framework (MacOS-specific AFAIK) - [ ] -time - [ ] -static-openmp # generally useful in LLVM projects - [ ] -mllvm - [ ] -mmlir # code generation flags that have known utility - [ ] -mno-gather - [ ] -mno-scatter - [ ] -mrecip ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89885] Difference between compile-time and runtime float precision on 32-bit x86 without SSE can cause miscompilation leading to segfault
Issue
89885
Summary
Difference between compile-time and runtime float precision on 32-bit x86 without SSE can cause miscompilation leading to segfault
Labels
new issue
Assignees
Reporter
beetrees
The following program (based on the Rust version from [here](https://github.com/rust-lang/rust/issues/114479#issuecomment-2072945866), which is based on @comex's example from a different issue; they gave an explanation of they found it [here](https://github.com/rust-lang/unsafe-code-guidelines/issues/471#issuecomment-1774261953))
```c
#include
#include
void print_vals(float x, size_t i, int vals_i) {
printf("x=%f i=%zu vals[i]=%i\n", x, i, vals_i);
}
void out_of_bounds(float x, size_t i) {
printf("x=%f i=%zu vals[i]=out of bounds\n", x, i);
}
void evil(int vals[300]) {
float x = 0.0;
size_t i = 0;
while (x != 90.0) {
// At compile time, LLVM will brute-force the loop and discover that it
// terminates after 90 iterations, with `i` always less than 300. This bounds
// check therefore gets optimised out.
if (i < 300) {
print_vals(x, i, vals[i]);
} else {
out_of_bounds(x, i);
}
x += 1.0;
// This addition is too small to have any effect on the value of `x` with
// regular `float` precision, which is what LLVM uses at compile-time.
// However, with the extra precision offered by x87 floating point registers,
// the value of `x` will change slightly, meaning it will never hit exactly
// 90.0 and therefore the loop will never terminate at runtime.
x += 2.9802322387695312e-08;
i += 2;
}
}
int main() {
int vals[300];
for (int i = 0; i < 300; i++) {
vals[i] = i;
}
evil(vals);
}
```
compiled with `clang -O3 --target=i686-unknown-linux-gnu -mno-sse code.c` will segfault at runtime. This is due to LLVM evaluating floats at standard float precision at compile-time, but outputting machine code that uses x87 extended precision at runtime. Specifically, [llvm/lib/Analysis/ScalarEvolution.cpp](https://github.com/llvm/llvm-project/blob/46b011d0ccb468613bcc7e9e756518f9f383001d/llvm/lib/Analysis/ScalarEvolution.cpp) will brute force the loop using compile-time semantics, causing the bounds check to be optimised out; however the extra precision of x87 extended precision floats will mean that the loop termination condition is never hit at runtime.
The [LangRef](https://llvm.org/docs/LangRef.html#floatenv) appears to imply that the compile-time semantics are correct, so this is a bug in the x86 backend.
Related to #44218.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 89878] Flang's CompilerInvocation.cpp should not copy->paste->edit from Clang's CompilerInvocation.cpp
Issue
89878
Summary
Flang's CompilerInvocation.cpp should not copy->paste->edit from Clang's CompilerInvocation.cpp
Labels
flang:driver
Assignees
Reporter
jeffhammond
Consider `parseShowColorsArgs` from flang/lib/Frontend/CompilerInvocation.cpp and clang/lib/Frontend/CompilerInvocation.cpp. The function has been copied almost verbatim except:
- Flang doesn't rely on `using namespace llvm::opt;`
- whitespace
- `showColors` and `value` follows a different case convention
- variable named `opt` instead of `O`
- default argument different, comment about it
Using copy->paste->edit like this tedious and error-prone. Any bugs in the Clang driver code will need to be fixed manually a second time in Flang. Due to the syntax changes that have no impact on code generation, this won't be as trivial because the patch to Flang will have to use the new variable names.
This code should be properly abstracted and reused.
Furthermore, Flang should follow https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly.
```diff
< static bool parseShowColorsArgs(const llvm::opt::ArgList ,
< bool defaultColor = true) {
< // Color diagnostics default to auto ("on" if terminal supports) in the
< // compiler driver `flang-new` but default to off in the frontend driver
< // `flang-new -fc1`, needing an explicit OPT_fdiagnostics_color.
---
> static bool parseShowColorsArgs(const ArgList , bool DefaultColor) {
> // Color diagnostics default to auto ("on" if terminal supports) in the driver
> // but default to off in cc1, needing an explicit OPT_fdiagnostics_color.
12,27c10,24
< } showColors = defaultColor ? Colors_Auto : Colors_Off;
<
< for (auto *a : args) {
< const llvm::opt::Option = a->getOption();
< if (opt.matches(clang::driver::options::OPT_fcolor_diagnostics)) {
< showColors = Colors_On;
< } else if (opt.matches(clang::driver::options::OPT_fno_color_diagnostics)) {
< showColors = Colors_Off;
< } else if (opt.matches(clang::driver::options::OPT_fdiagnostics_color_EQ)) {
< llvm::StringRef value(a->getValue());
< if (value == "always")
< showColors = Colors_On;
< else if (value == "never")
< showColors = Colors_Off;
< else if (value == "auto")
< showColors = Colors_Auto;
---
> } ShowColors = DefaultColor ? Colors_Auto : Colors_Off;
> for (auto *A : Args) {
> const Option = A->getOption();
> if (O.matches(options::OPT_fcolor_diagnostics)) {
> ShowColors = Colors_On;
> } else if (O.matches(options::OPT_fno_color_diagnostics)) {
> ShowColors = Colors_Off;
> } else if (O.matches(options::OPT_fdiagnostics_color_EQ)) {
> StringRef Value(A->getValue());
> if (Value == "always")
> ShowColors = Colors_On;
> else if (Value == "never")
> ShowColors = Colors_Off;
> else if (Value == "auto")
> ShowColors = Colors_Auto;
30,32c27,28
<
< return showColors == Colors_On ||
< (showColors == Colors_Auto &&
---
> return ShowColors == Colors_On ||
> (ShowColors == Colors_Auto &&
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
