[llvm-bugs] [Bug 82230] opt -passes="instcombine" -debug
Issue 82230 Summary opt -passes="instcombine" -debug Labels new issue Assignees Reporter mikaelholmen llvm commit: d61864f813e3 Reproduce with: ``` opt -passes="instcombine" -debug bbi-92509.ll -o /dev/null ``` [bbi-92509.ll.gz](https://github.com/llvm/llvm-project/files/14329283/bbi-92509.ll.gz) Result: ``` INSTCOMBINE ITERATION #1 on func_10 ADD: ret ptr null ADD: store i64 %conv108, ptr null, align 1 ADD: br label %func_29.exit ADD: %conv108 = zext i32 %p_11 to i64 CLONE: PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: ../../main-github/llvm/build-all/bin/opt -passes=instcombine -debug bbi-92509.ll -o /dev/null #0 0x55e12968f4a7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (../../main-github/llvm/build-all/bin/opt+0x3db14a7) #1 0x55e12968cf7e llvm::sys::RunSignalHandlers() (../../main-github/llvm/build-all/bin/opt+0x3daef7e) #2 0x55e12968fe6f SignalHandler(int) Signals.cpp:0:0 #3 0x7fdf33999630 __restore_rt sigaction.c:0:0 #4 0x55e12971f8e0 llvm::DPMarker::getParent() const (../../main-github/llvm/build-all/bin/opt+0x3e418e0) #5 0x55e129761abf llvm::DPValue::print(llvm::raw_ostream&, bool) const (../../main-github/llvm/build-all/bin/opt+0x3e83abf) #6 0x55e12a244957 llvm::InstCombinerImpl::tryToSinkInstructionDPValues(llvm::Instruction*, llvm::ilist_iterator_w_bits, false, false>, llvm::BasicBlock*, llvm::BasicBlock*, llvm::SmallVectorImpl&) InstructionCombining.cpp:0:0 #7 0x55e12a242b0c llvm::InstCombinerImpl::tryToSinkInstruction(llvm::Instruction*, llvm::BasicBlock*) InstructionCombining.cpp:0:0 #8 0x55e12a2453fc llvm::InstCombinerImpl::run() InstructionCombining.cpp:0:0 #9 0x55e12a248c79 combineInstructionsOverFunction(llvm::Function&, llvm::InstructionWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, llvm::LoopInfo*, llvm::InstCombineOptions const&) InstructionCombining.cpp:0:0 #10 0x55e12a2482ea llvm::InstCombinePass::run(llvm::Function&, llvm::AnalysisManager&) (../../main-github/llvm/build-all/bin/opt+0x496a2ea) #11 0x55e12a95e5bd llvm::detail::PassModel>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #12 0x55e12989a8e4 llvm::PassManager>::run(llvm::Function&, llvm::AnalysisManager&) (../../main-github/llvm/build-all/bin/opt+0x3fbc8e4) #13 0x55e12a9644dd llvm::detail::PassModel>, llvm::AnalysisManager>::run(llvm::Function&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #14 0x55e12989f9ae llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager&) (../../main-github/llvm/build-all/bin/opt+0x3fc19ae) #15 0x55e12a95dd9d llvm::detail::PassModel>::run(llvm::Module&, llvm::AnalysisManager&) PassBuilderPipelines.cpp:0:0 #16 0x55e129899456 llvm::PassManager>::run(llvm::Module&, llvm::AnalysisManager&) (../../main-github/llvm/build-all/bin/opt+0x3fbb456) #17 0x55e12a90a42b llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef, llvm::ArrayRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (../../main-github/llvm/build-all/bin/opt+0x502c42b) #18 0x55e129657a28 optMain (../../main-github/llvm/build-all/bin/opt+0x3d79a28) #19 0x7fdf310cc555 __libc_start_main (/lib64/libc.so.6+0x22555) #20 0x55e129651369 _start (../../main-github/llvm/build-all/bin/opt+0x3d73369) Segmentation fault (core dumped) ``` This starts happening with a93a4ec7dd205 ``` Reapply "[DebugInfo][RemoveDIs] Turn on non-instrinsic debug-info by default" ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82235] [mlir] --convert-func-to-llvm sets llvm data layout attribute to an empty string (tested on llvm 17.0.2)
Issue
82235
Summary
[mlir] --convert-func-to-llvm sets llvm data layout attribute to an empty string (tested on llvm 17.0.2)
Labels
mlir
Assignees
Reporter
edg-l
```
module attributes {llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", llvm.target_triple = "x86_64-unknown-linux-gnu"} {
func.func @main() {
return
}
}
```
```bash
mlir-opt minimal.mlir --convert-func-to-llvm
module attributes {llvm.data_layout = "", llvm.target_triple = "x86_64-unknown-linux-gnu"} {
llvm.func @main() {
llvm.return
}
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82241] [InstCombine] Failure to convert vector fp comparisons thath can be represented as integers
Issue
82241
Summary
[InstCombine] Failure to convert vector fp comparisons thath can be represented as integers
Labels
llvm:instcombine,
missed-optimization
Assignees
Reporter
RKSimon
https://rust.godbolt.org/z/dfWjnToef
We will simplify a comparison of scalar floats that can be represented as integers to compare the integers directly, but we don't do this for vectors:
```ll
define i32 @cmpf(i32 %x) {
%and = and i32 %x, 3
%conv = sitofp i32 %and to float
%cmp = fcmp oeq float %conv, 3.00e+00
%sext = sext i1 %cmp to i32
ret i32 %sext
}
define <8 x i32> @vcmpf(<8 x i32> %x) {
%and = and <8 x i32> %x,
%conv = sitofp <8 x i32> %and to <8 x float>
%cmp = fcmp oeq <8 x float> %conv,
%sext = sext <8 x i1> %cmp to <8 x i32>
ret <8 x i32> %sext
}
```
opt -O3
```ll
define i32 @cmpf(i32 %x) {
%and = and i32 %x, 3
%cmp = icmp eq i32 %and, 3
%sext = sext i1 %cmp to i32
ret i32 %sext
}
define <8 x i32> @vcmpf(<8 x i32> %x) {
%and = and <8 x i32> %x,
%conv = sitofp <8 x i32> %and to <8 x float>
%cmp = fcmp oeq <8 x float> %conv,
%sext = sext <8 x i1> %cmp to <8 x i32>
ret <8 x i32> %sext
}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82242] [X86] Attempt to perform AVX1 v8i32 integer comparisons as v8f32
Issue
82242
Summary
[X86] Attempt to perform AVX1 v8i32 integer comparisons as v8f32
Labels
backend:X86,
missed-optimization
Assignees
Reporter
RKSimon
```cpp
__v8si vcmpi(__v8si x) {
__v8si M = (__v8si) {K,K,K,K,K,K,K,K};
x &= M;
return x == M;
}
__v8si vcmpf(__v8si x) {
__v8si M = (__v8si) {K,K,K,K,K,K,K,K};
x &= M;
return __builtin_convertvector(x,__v8sf) == __builtin_convertvector(M, __v8sf);
}
```
```ll
define <8 x i32> @vcmpi(<8 x i32> %x) {
%and = and <8 x i32> %x,
%cmp = icmp eq <8 x i32> %and,
%sext = sext <8 x i1> %cmp to <8 x i32>
ret <8 x i32> %sext
}
define <8 x i32> @vcmpf(<8 x i32> %x) {
%and = and <8 x i32> %x,
%conv = sitofp <8 x i32> %and to <8 x float>
%cmp = fcmp oeq <8 x float> %conv,
%sext = sext <8 x i1> %cmp to <8 x i32>
ret <8 x i32> %sext
}
```
AVX1 targets have to split/concat 256-bit integer comparisons, but if we can confirm that the integer values are exactly representable as integers then it can be worth converting to floats and perform as a fp comparison.
llvm-mca: https://llvm.godbolt.org/z/5Tns64zGP
This came up on some sincos implementations where most of the code is 256-bit fp, but we were having to convert to int to compute the quadrant (0 - 3) special cases.
Invert of #82241
___
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 #5 on issue 65993 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65993#c5 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-2164f746-5ad1-47d8-b249-9451953c168e.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 82243] Wrong code at -Os on x86-64_gnu-linux (recent regression)
Issue
82243
Summary
Wrong code at -Os on x86-64_gnu-linux (recent regression)
Labels
new issue
Assignees
Reporter
shao-hua-li
Clang at -Os produced the wrong code.
Bisected to dce77a357948709e335910ddc07f9c3f2eb2ac4b, which was committed by @fhahn
Compiler explorer: https://godbolt.org/z/fTrenPK4h
```console
% cat reduced.c
int printf(const char *, ...);
int a, b, c, d, e;
int f[9];
int g(int i) {
c = 1 << i;
if (b & c)
return 4;
return 0;
}
int j(int i) {
int h = g(i);
return h;
}
int k() {
d = 6;
for (; d; d--) {
e = 0;
for (; e <= 6; e++) {
f[j(d - 1)] = f[d];
for (; e + d;)
return 0;
}
}
return 0;
}
int main() {
k();
printf("%d\n", a);
}
%
% clang -O3 reduced.c && ./a.out
0
% clang -Os reduced.c && ./a.out
%
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82246] `clang-format` and `clang-format --dry-run -Werror` disagree regarding inline namespace
Issue
82246
Summary
`clang-format` and `clang-format --dry-run -Werror` disagree regarding inline namespace
Labels
clang-format
Assignees
Reporter
uyha
with the following snippet (`sample.cpp`)
```cpp
namespace name::inline name {
struct {
} a;
}
```
running `clang-format -i sample.cpp` will produce
```cpp
namespace name::inline name {
struct {
} a;
} // namespace name::inline name
```
However, running `clang-format sample.cpp | clang-format --dry-run -Werror` will produce an error saying
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82249] Member `operator new` and `operator delete` should reject explicit object parameters
Issue
82249
Summary
Member `operator new` and `operator delete` should reject explicit object parameters
Labels
new issue
Assignees
Reporter
Rajveer100
These functions are members, but they are implicitly static members as in this [draft](https://eel.is/c++draft/class#free-3), which means they shouldn't be allowed to have explicit object parameters.
Snippet:
```C++
#include
#include
struct S {
void *operator new(this unsigned long);
void operator delete(this void*);
void operator delete(this S*, std::destroying_delete_t);
};
```
[GodBolt](https://godbolt.org/z/vG16GEzGM)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82252] aarch64 unconditionally spills when x86-64 does not
Issue
82252
Summary
aarch64 unconditionally spills when x86-64 does not
Labels
new issue
Assignees
Reporter
jrmuizel
Give the following code:
```c++
extern void foo();
struct Vertex {
float x;
float y;
float c;
};
class Foo {
void write_vertex(float x1, float y1, float c1, float x2, float y2, float c2, float x3, float y3, float c3);
Vertex *ptr;
};
int blue;
void Foo::write_vertex(float x1, float y1, float c1, float x2, float y2, float c2, float x3, float y3, float c3){
Vertex v1 = {x1, y1, c1};
Vertex v2 = {x2, y2, c2};
Vertex v3 = {x3, y3, c3};
if (blue) {
ptr[0] = v1;
ptr[1] = v2;
ptr[3] = v3;
} else{
foo();
ptr[0] = v1;
ptr[1] = v2;
ptr[3] = v3;
}
}
```
The generated x86-64 code only stores to the stack when calling `foo()` however the aarch64 code always spills:
```
Foo::write_vertex(float, float, float, float, float, float, float, float, float):// @Foo::write_vertex(float, float, float, float, float, float, float, float, float)
stp d15, d14, [sp, #-96]! // 16-byte Folded Spill
stp d13, d12, [sp, #16] // 16-byte Folded Spill
stp d11, d10, [sp, #32] // 16-byte Folded Spill
stp d9, d8, [sp, #48] // 16-byte Folded Spill
stp x29, x30, [sp, #64] // 16-byte Folded Spill
str x19, [sp, #80] // 8-byte Folded Spill
add x29, sp, #64
fmovs9, s6
fmovs10, s5
adrpx8, blue
fmovs11, s4
fmovs12, s3
ldr w8, [x8, :lo12:blue]
fmovs13, s2
fmovs14, s1
ldr s8, [x29, #32]
fmovs15, s0
mov x19, x0
cbnzw8, .LBB0_2
str s7, [x29, #28] // 4-byte Folded Spill
bl foo()
ldr s7, [x29, #28] // 4-byte Folded Reload
.LBB0_2:
ldr x8, [x19]
stp s15, s14, [x8]
stp s13, s12, [x8, #8]
stp s11, s10, [x8, #16]
stp s9, s7, [x8, #36]
str s8, [x8, #44]
ldp x29, x30, [sp, #64] // 16-byte Folded Reload
ldr x19, [sp, #80] // 8-byte Folded Reload
ldp d9, d8, [sp, #48] // 16-byte Folded Reload
ldp d11, d10, [sp, #32] // 16-byte Folded Reload
ldp d13, d12, [sp, #16] // 16-byte Folded Reload
ldp d15, d14, [sp], #96 // 16-byte Folded Reload
ret
blue:
.word 0
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82258] Crash in frontend when trying examples of P2564R3 (propagating consteval)
Issue
82258
Summary
Crash in frontend when trying examples of P2564R3 (propagating consteval)
Labels
new issue
Assignees
Reporter
loic-joly-sonarsource
Link to compiler explorer reproducer: https://godbolt.org/z/Gnr3bbnej
The following code, extracted from [P2564R3](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2564r3.html) (consteval needs to propagate up), crashed the frontend:
```cpp
static_assert(none_of(
types,
[]{
return is_invalid;
}()
));
```
Excerpt from the call stack:
```
#4 0x00b0c48a clang::Sema::MarkExpressionAsImmediateEscalating(clang::Expr*) (.cold) SemaExpr.cpp:0:0
#5 0x06280f7d clang::Sema::PopExpressionEvaluationContext() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6280f7d)
#6 0x0646e5d2 clang::Sema::BuildLambdaExpr(clang::SourceLocation, clang::SourceLocation, clang::sema::LambdaScopeInfo*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x646e5d2)
#7 0x06472b61 clang::Sema::ActOnLambdaExpr(clang::SourceLocation, clang::Stmt*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x6472b61)
#8 0x05d79ed7 clang::Parser::ParseLambdaExpressionAfterIntroducer(clang::LambdaIntroducer&) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5d79ed7)
#9 0x05d7b8ab clang::Parser::ParseLambdaExpression() (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5d7b8ab)
#10 0x05d58dcb clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5d58dcb)
#11 0x05d5a76a clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, clang::Parser::TypeCastState, bool, bool*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x5d5a76a)
```
Additionally, the following similar code, which is supposed to work, does not crash but fails to compile:
```cpp
static_assert(none_of(
types,
+[](info i) consteval {
return is_invalid(i);
}
));
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82259] llvm-cov: wrong line coverage count for first line after condition in macro
Issue
82259
Summary
llvm-cov: wrong line coverage count for first line after condition in macro
Labels
new issue
Assignees
Reporter
ManuelvOK
In code with conditions in macros, the first line after the condition has the same count as the condition itself even if it is not executed.
`llvm-cov show` results in the following:
```
1| |# define RET\
2| 1|if (0) \
3| 1| return 1; \
4| 1|return 0;
5| |
6| 1|int main() {
7| 1| RET
8| 1|}
```
With a purple line count `1` in line 2 and a red background on the `return 1;` in line 3.
Using braces on dedicated lines kind of circumvents the issue:
```
1| |# define RET \
2| 1|if (0) \
3| 1|{ \
4| 0| return 1; \
5| 0|} \
6| 1|return 0;
7| |
8| 1|int main() {
9| 1|RET
10| 1|}
```
Again, with a purple line count `1` in line 2, but now the red background spans from `{` to `}`.
Removing the macro while containing the backslashes leads to the correct line counts:
```
1| 1|int main() {
2| 1| if (0) \
3| 0| return 1; \
4| 1| return 0;
5| 1|}
```
The line count calculation inside and outside macros should be consistent.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82260] Synthetic children not working for certain types in lldb
Issue
82260
Summary
Synthetic children not working for certain types in lldb
Labels
new issue
Assignees
Reporter
wolfpld
I'm trying to add a synthetic children provider for the `__m128i` type, but I'm not able to get it to work properly.
I have the following script (`simd.py`) that I hook to lldb:
```python
import lldb
class TestPrinter:
def __init__(self, valobj, internal_dict):
self.valobj = valobj
def update(self):
logger = lldb.formatters.Logger.Logger()
logger >> "update"
def num_children(self):
logger = lldb.formatters.Logger.Logger()
logger >> "num_children"
return 4
def get_child_index(self, name):
logger = lldb.formatters.Logger.Logger()
logger >> "get_child_index: " + name
return int(name.lstrip('[').rstrip(']'))
def get_child_at_index(self, index):
logger = lldb.formatters.Logger.Logger()
logger >> "get_child_index: " + str(index)
match index:
case 0:
return self.valobj.CreateValueFromExpression('u8x16', 'nullptr')
case 1:
return self.valobj.CreateValueFromExpression('i8x16', 'nullptr')
case 2:
return self.valobj.CreateValueFromExpression('u16x8', 'nullptr')
case 3:
return self.valobj.CreateValueFromExpression('i16x8', 'nullptr')
case _:
return None
def __lldb_init_module(debugger, dict):
lldb.formatters.Logger._lldb_formatters_debug_level = 2
debugger.HandleCommand('type synthetic add -w simd -l simd.TestPrinter __m128i')
debugger.HandleCommand('type synthetic add -w simd -l simd.TestPrinter TestType')
debugger.HandleCommand('type category enable simd')
```
Test program:
```c++
#include
struct TestType
{
int a;
int b;
};
int main()
{
TestType tt;
__m128i simd;
}
```
Debugger behavior:
```
(lldb) b a.cpp:13
Breakpoint 1: where = a.out`main + 4 at a.cpp:13:1, address = 0x1124
(lldb) r
Process 3664 launched: '/home/wolf/a.out' (x86_64)
Process 3664 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x5124 a.out`main at a.cpp:13:1
10 {
11 TestType tt;
12 __m128i simd;
-> 13 }
(lldb) v tt
update
num_children
get_child_index: 0
update
num_children
get_child_index: 1
update
num_children
get_child_index: 2
update
num_children
get_child_index: 3
update
num_children
get_child_index: 0
update
get_child_index: 1
update
get_child_index: 2
update
get_child_index: 3
(TestType) tt = (u8x16 = 0x, i8x16 = 0x, u16x8 = 0x, i16x8 = 0x)
(lldb) v simd
update
(__m128i) simd = (140737353696512, 3348558691198135399)
(lldb)
```
In case of the `TestType` type all the expected methods are called and synthetic children are printed. In case of `__m128i` only a single call to `update` is executed, and then pretty printing is no longer in action.
It is possible to reference the synthetic children individually in `__m128i`, in which case the pretty printer is invoked as expected.
```
(lldb) v simd[0]
num_children
get_child_index: 0
(std::nullptr_t) u8x16 = 0x
```
This behavior can be observed on `lldb version 16.0.6` and `lldb version 19.0.0git (https://github.com/llvm/llvm-project.git revision 652081ca9eefc910bbd3257bac9b2bb44756aa21)`
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82261] Mach-O check for improperly nested .cfi_* regions doesn't take .alt_entry into account
Issue 82261 Summary Mach-O check for improperly nested .cfi_* regions doesn't take .alt_entry into account Labels new issue Assignees Reporter Amanieu This issue was hit in https://github.com/Amanieu/corosensei/issues/23 where we have code that looks like this: ```asm .globl _stack_init_trampoline .private_extern _stack_init_trampoline _stack_init_trampoline: .cfi_startproc [...] .alt_entry _stack_init_trampoline_return .globl _stack_init_trampoline_return .private_extern _stack_init_trampoline_return _stack_init_trampoline_return: [...] .cfi_endproc ``` This currently produces the following error due to https://reviews.llvm.org/D155245: ``` error: non-private labels cannot appear between .cfi_startproc / .cfi_endproc pairs ``` However I think (I am not an expert in Mach-O) that this should be valid since the inner label is properly marked with `.alt_entry`. cc @jroelofs ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82263] polly: 3 * trivial performance issues
Issue 82263 Summary polly: 3 * trivial performance issues Labels new issue Assignees Reporter dcb314 Static analyser cppcheck says: polly/lib/Support/GICHelper.cpp:89:64: performance: Function parameter 'DefaultValue' should be passed by const reference. [passedByValue] polly/lib/Transform/MatmulOptimizer.cpp:637:62: performance: Function parameter 'MMI' should be passed by const reference. [passedByValue] polly/lib/Transform/MatmulOptimizer.cpp:714:35: performance: Function parameter 'MMI' should be passed by const reference. [passedByValue] This issue would be suitable for a new starter. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82266] "Embedding LLVM in your project" needs an update.
Issue 82266 Summary "Embedding LLVM in your project" needs an update. Labels new issue Assignees Reporter dabrahams Per [this comment](https://github.com/llvm/llvm-project/issues/34593#issuecomment-980988801), ["Embedding LLVM in your project"](https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project) has been inaccurate and out-of-date going on 7 years. Someone who knows what it should really say should probably write that down before all such people have left the stage… ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82267] [Flang] BINC(C) attribute not propagate to the generic name that is the same as the specific name that has the BIND(C) attribute.
Issue 82267 Summary [Flang] BINC(C) attribute not propagate to the generic name that is the same as the specific name that has the BIND(C) attribute. Labels bug, flang:frontend Assignees Reporter DanielCChen Consider the following code: ``` MODULE M USE ISO_C_BINDING INTERFACE ExtFun FUNCTION ExtFun() BIND(C) IMPORT INTEGER(C_INT) :: ExtFun END FUNCTION END INTERFACE END MODULE PROGRAM MAIN USE M PROCEDURE(ExtFun), BIND(C), POINTER :: PExtFun END ``` Flang currently issues an error as: ``` : error: An interface name with BIND attribute must be specified if the BIND attribute is specified in a procedure declaration statement PROCEDURE(ExtFun), BIND(C), POINTER :: PExtFun ^^^ ``` It passes if I remove the generic name. The `BIND(C)` attribute seems missing from both the generic and specific symbol in the dump. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82271] [ConstraintElimination] Missed optimization: fold `max(Ext(b), Ext(a) + 1)` to `Ext(b)` if `a s< b`
Issue
82271
Summary
[ConstraintElimination] Missed optimization: fold `max(Ext(b), Ext(a) + 1)` to `Ext(b)` if `a s< b`
Labels
new issue
Assignees
Reporter
XChy
Alive2 proof: https://alive2.llvm.org/ce/z/A8dtGp
### Motivating example
Similar to #75155
```llvm
define i64 @src(i32 %a, i32 %b){
entry:
%cmp = icmp slt i32 %a, %b
br i1 %cmp, label %then, label %else
then:
%sa = sext i32 %a to i64
%sb = sext i32 %b to i64
%add = add i64 %sa, 1
%smax = call i64 @llvm.smax.i64(i64 %sb, i64 %add)
call void @dummy()
ret i64 %smax
else:
ret i64 0
}
```
can be folded to:
```llvm
define i64 @tgt(i32 %a, i32 %b){
entry:
%cmp = icmp slt i32 %a, %b
br i1 %cmp, label %then, label %else
then:
%sb = sext i32 %b to i64
call void @dummy()
ret i64 %sb
else:
ret i64 0
}
```
And for the unsigned version, we missed it too.
AFAIK, ConstraintElimination folds `ZExt(a) < ZExt(b)` to `true` if `a u< b`, so I tag ConstraintElimination here.
### Real-world motivation
This snippet of IR is derived from [redis/src/db.c@xreadGetKeys](https://github.com/redis/redis/blob/6df42df2917622cfe791b0f563fa82053965820f/src/db.c#L2554) (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/Kz4M6WPxn
**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 82286] _Atomic type qualifier when initializing aggregates fails
Issue
82286
Summary
_Atomic type qualifier when initializing aggregates fails
Labels
new issue
Assignees
Reporter
gitrj95
The following:
```
struct R {
int a;
};
int main(void) {
struct R _Atomic a = {0};
return 0;
}
```
fails with:
```
a.c:6:24: error: illegal initializer type '_Atomic(struct R)'
struct R _Atomic a = {0};
^
1 error generated.
```
on "trunk" as specified by godbolt. This succeeds with the latest gcc, and is a valid grammar for initializing atomic-qualified types in C.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82288] [clang-format] Multiple WhitespaceSensitiveMacros in function call break indention
Issue
82288
Summary
[clang-format] Multiple WhitespaceSensitiveMacros in function call break indention
Labels
new issue
Assignees
Reporter
p3732
This is very similar to https://github.com/llvm/llvm-project/issues/55443
With the whitespace macros being also defined as macros, the indention will only break for other usages of the same whitespace sensitive macro.
Example
```
create_dialog (_("Dialog Title"),
other_parameter,
_("Cancel"), CANCEL_ENUM_VALUE,
_("OK"), OK_ENUM_VALUE);
```
ends up being formatted as
```
create_dialog (_("Dialog Title"),
other_parameter,
_("Cancel"), CANCEL_ENUM_VALUE,
_("OK"), OK_ENUM_VALUE);
```
Full config
```
---
AlignAfterOpenBracket: Align
AlignConsecutiveDeclarations: true
AlignConsecutiveShortCaseStatements:
Enabled: true
AlignOperands: Align
AllowShortCaseLabelsOnASingleLine: true
AllowShortEnumsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: false
AlwaysBreakAfterReturnType: AllDefinitions
BinPackParameters: false
BreakArrays: true
BreakBeforeBraces: Allman
ColumnLimit: 0
Cpp11BracedListStyle: false
IndentCaseBlocks: false
IndentCaseLabels: true
IndentWidth: 4
InsertNewlineAtEOF: true
LineEnding: LF
ReflowComments: true
ExperimentalAutoDetectBinPacking: true
PenaltyBreakAssignment: 1000
PenaltyBreakBeforeFirstCallParameter: 1000
PenaltyBreakOpenParenthesis: 1000
PointerAlignment: Right
SeparateDefinitionBlocks: Always
SpaceAfterCStyleCast: true
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: Always
SpacesBeforeTrailingComments: 1
SpacesInParens: Never
Macros:
- _(x)=x,
WhitespaceSensitiveMacros:
- _
- N_
- C_
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 82307] [libFuzzer] Incorrect coverage number in fork mode
Issue 82307 Summary [libFuzzer] Incorrect coverage number in fork mode Labels new issue Assignees Reporter yescallop When running the fuzzer in fork mode, the coverage number starts out always the same as the feature number, for example: ``` #109599: cov: 10365 ft: 10365 corp: 6188 exec/s 54799 oom/timeout/crash: 0/0/0 time: 2s job: 1 dft_time: 0 ``` This does not happen when running the fuzzer in normal mode: ``` #10090 INITED cov: 2273 ft: 10366 corp: 6173/210Kb exec/s: 0 rss: 179Mb ``` I believe that this is caused by the following line: https://github.com/llvm/llvm-project/blob/d9f9775ac6289271d57671c55166fa0cad61075b/compiler-rt/lib/fuzzer/FuzzerFork.cpp#L352 I'll open a pull request after I figure out how to test my change. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
