[llvm-bugs] [Bug 146335] clang crash for fopenmp statement(parallel for) inside lambda function while generating llvm-ir
Issue
146335
Summary
clang crash for fopenmp statement(parallel for) inside lambda function while generating llvm-ir
Labels
clang
Assignees
Reporter
suganyat14
clang crashes with following stack for debug build as follows:
clang++ -fopenmp lambda_iter.cpp
lambda_iter.cpp:15:3: warning: missing 'typename' prior to dependent type name 'l::h' is a C++20 extension [-Wc++20-extensions]
15 | l::h aa;
| ^
| typename
lambda_iter.cpp:52:20: warning: field 'q' is uninitialized when used here [-Wuninitialized]
52 | H(n ag, m r) : D(q, 0, ag, r, v), t{o(af, 0, 0)} {}
| ^
lambda_iter.cpp:52:33: warning: field 'v' is uninitialized when used here [-Wuninitialized]
52 | H(n ag, m r) : D(q, 0, ag, r, v), t{o(af, 0, 0)} {}
| ^
lambda_iter.cpp:52:41: warning: field 'af' is uninitialized when used here [-Wuninitialized]
52 | H(n ag, m r) : D(q, 0, ag, r, v), t{o(af, 0, 0)} {}
| ^
DeclRefExpr for Decl not entered in LocalDeclMap?
UNREACHABLE executed at /home/suganya/upstream_llvm/llvm-project/clang/lib/CodeGen/CGExpr.cpp:3260!
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: /home/suganya/upstream_llvm/build/bin/clang-21 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -dumpdir a- -disable-free -clear-ast-before-backend -main-file-name lambda_iter.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -fdebug-compilation-dir=/home/suganya -fcoverage-compilation-dir=/home/suganya -resource-dir /home/suganya/upstream_llvm/build/lib/clang/21 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/backward -internal-isystem /home/suganya/upstream_llvm/build/lib/clang/21/include -internal-isystem /usr/local/include -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -ferror-limit 19 -fopenmp -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/lambda_iter-1675e7.o -x c++ lambda_iter.cpp
1. parser at end of file
2. Per-file LLVM IR generation
3. lambda_iter.cpp:58:13: Generating code for declaration 'F::ak(H &)::(anonymous class)::operator()'
#0 0x5dfda87f5210 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
Example: (Reduced example of SIRIUS library application using creduce)
enum a {};
class b {
public:
b(int);
};
struct c {
typedef b h;
};
using e = b;
using f = b;
template class g {};
template class i {
public:
using j = long;
l::h aa;
i(g) : aa{0} {}
bool operator!=(i);
void operator++();
auto operator*() {
int k;
return k;
}
j operator-(i);
void operator+=(j);
};
class o : public g {
public:
using p = int;
o(p, e, f);
};
auto begin(g ac) {
i ad(ac);
return ad;
}
template auto end(l ac) {
i ad(ac);
return ad;
}
using m = b;
using n = b;
class D {
protected:
D(int, int, n, m, a);
};
class H : D {
int af;
o t;
public:
a v;
int q;
H(n ag, m r) : D(q, 0, ag, r, v), t{o(af, 0, 0)} {}
auto s() { return t; }
};
template class F { void ak(H &) const; };
template void F::ak(H &an) const {
auto ao = an.s();
auto ap = [ao](H) {
#pragma omp for
for (auto d : ao)
;
};
H ar(0, 0);
ap(ar);
}
template class F;
With release llvm binaries, it compiles successfully.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146341] [BUG][AArch64] clang frontend command failed with exit code 136
Issue 146341 Summary [BUG][AArch64] clang frontend command failed with exit code 136 Labels clang Assignees Reporter loadstore Issue encountered when compiling Spec2006 403.gcc with -march=armv9.4 or later (works fine for -march=armv9.3 or before). Stack traces are: Stack dump: 0. Program arguments: /scratch-1/resource/llvm-toolchain/install_main_release/bin/clang -c -o c-typeck.o -DSPEC_CPU -DNDEBUG -I. -O3 -march=armv9.6-a -fno-strict-aliasing -target aarch64-none-linux-gnu --sysroot=/scratch-1/resource/arm-gnu-toolchain-12.2.rel1-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc --gcc-toolchain=/scratch-1/resource/arm-gnu-toolchain-12.2.rel1-x86_64-aarch64- none-linux-gnu -DSPEC_CPU_LP64 c-typeck.c 1. parser at end of file 2. Optimizer 3. Running pass "function(float2int,lower-constant-intrinsics,chr,loop(loop-rotate,loop-deletion),loop-distribute,inject-tli-mappings,loop- vectorize,infer-alignment,loop-load-elim,instcombine,simplifycfg,slp- vectorizer,vector-combine,instcombine,loop-unroll,transform-warning,sroa,infer-alignment,instcombine,loop- mssa(licm),alignment-from-assumptions,loop-sink,instsimplify,div-rem-pairs,tailcallelim,simplifycfg)" on module "c-typeck.c" 4. Running pass "slp-vectorizer" on function "digest_init" #0 0x7f070f1eab17 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMSupport.so.21.0git+0x186b17) #1 0x7f070f1e88d5 llvm::sys::RunSignalHandlers() (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMSupport.so.21.0git+0x1848d5) #2 0x7f070f1e9fed llvm::sys::CleanupOnSignal(unsigned long) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMSupport.so.21.0git+0x185fed) #3 0x7f070f126b1f CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0 #4 0x7f071293f420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420) #5 0x7f0712decc60 llvm::AArch64TTIImpl::getShuffleCost(llvm::TargetTransformInfo::ShuffleKind, llvm::VectorType*, llvm::VectorType*, llvm::ArrayRef, llvm::TargetTransformInfo::TargetCostKind, int, llvm::VectorType*, llvm::ArrayRef, llvm::Instruction const*) const (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMAArch64CodeGen.so.21.0git+0x2f2c60) #6 0x7f07111f5079 llvm::slpvectorizer::BoUpSLP::ShuffleCostEstimator::ShuffleCostBuilder::createShuffleVector(llvm::Value*, llvm::ArrayRef) const (/scratch-1/resource/llvm-toolchain/ install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+0x1c0079) #7 0x7f07111f39b3 llvm::slpvectorizer::BoUpSLP::ShuffleCostEstimator::createShuffle(llvm::PointerUnion const&, llvm:: PointerUnion const&, llvm::ArrayRef) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+ 0x1be9b3) #8 0x7f07111ec5d4 llvm::slpvectorizer::BoUpSLP::ShuffleCostEstimator::finalize(llvm::ArrayRef, llvm::ArrayRef>, llvm:: ArrayRef, unsigned int, llvm::function_ref&, llvm::function_ref)>)>) (/scratch-1/ resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+0x1b75d4) #9 0x7f071115794f llvm::InstructionCost llvm::slpvectorizer::BoUpSLP::processBuildVector, llvm::slpvectorizer::BoUpSLP, llvm::SmallPtrSetImpl>(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::Type*, llvm::TargetTransformInfo&, llvm::ArrayRef&, llvm::slpvectorizer::BoUpSLP&, llvm::SmallPtrSetImpl&) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+0x12294f) #10 0x7f0711150f2e llvm::slpvectorizer::BoUpSLP::getEntryCost(llvm::slpvectorizer::BoUpSLP::TreeEntry const*, llvm::ArrayRef, llvm::SmallPtrSetImpl&) (/scratch-1/ resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+0x11bf2e) #11 0x7f071115df09 llvm::slpvectorizer::BoUpSLP::getTreeCost(llvm::ArrayRef, llvm::InstructionCost) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/ libLLVMVectorize.so.21.0git+0x128f09) #12 0x7f07111cc22b (anonymous namespace)::HorizontalReduction::tryToReduce(llvm::slpvectorizer::BoUpSLP&, llvm::DataLayout const&, llvm::TargetTransformInfo*, llvm::TargetLibraryInfo const&, llvm:: AssumptionCache*) SLPVectorizer.cpp:0:0 #13 0x7f071119ab89 llvm::SLPVectorizerPass::vectorizeHorReduction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&, llvm::SmallVectorImpl&) (/scratch-1/resource/llvm-toolchain/install_main_release/bin/../lib/libLLVMVectorize.so.21.0git+0x165b89) #14 0x7f071119af47 llvm::SLPVectorizerPass::vectorizeRootInstruction(llvm::PHINode*, llvm::Instruction*, llvm::BasicBlock*, llvm::slpvectorizer::BoUpSLP&) (/scratch-1/resource/llvm-toolchain/ in
[llvm-bugs] [Bug 146344] Incorrect usage of variable in CMakeLists.txt
Issue
146344
Summary
Incorrect usage of variable in CMakeLists.txt
Labels
new issue
Assignees
Reporter
x12301450
In mlir/lib/Target/LLVM/CMakeLists.txt, the variable `CUDAToolkit_LIBRARY_ROOT` is used in the following way in Line 66:
`set(MLIR_CUDAToolkit_ROOT ${CUDAToolkit_LIBRARY_ROOT})`
and like this in Line 135:
```
find_file(MLIR_NVVM_LIBDEVICE_PATH libdevice.10.bc
PATHS ${CUDAToolkit_LIBRARY_ROOT}
PATH_SUFFIXES "nvvm/libdevice" NO_DEFAULT_PATH REQUIRED)
```
However, when checking whether the variable is defined, it is done in the following way in Line 62:
`if(NOT DEFINED ${CUDAToolkit_LIBRARY_ROOT})`
This `if` command doesn't take effect when `CUDAToolkit_LIBRARY_ROOT` simply represent a path. I think the correct way to write it should be:
`if(NOT DEFINED CUDAToolkit_LIBRARY_ROOT)`
Looking forward to your feedback!
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146324] [clang-tidy] `bugprone-unhandled-self-assignment` doesn't know about allocator arguments to copy/move constructors
Issue
146324
Summary
[clang-tidy] `bugprone-unhandled-self-assignment` doesn't know about allocator arguments to copy/move constructors
Labels
clang-tidy
Assignees
Reporter
MikeWeller
I may have copy/move constructors that take an additional allocator argument (similar to `vector( const vector& other, const Allocator& alloc );`). Additionally, the type may use the [leading-allocator convention](https://en.cppreference.com/w/cpp/memory/uses_allocator.html) with `std::allocator_arg_t`.
If I call one of these "extended" copy/move constructors in my copy/move-and-swap idiom, `bugprone-unhandled-self-assignment` doesn't recognize it and produces a false positive warning (copy-and-swap/move should not trigger the warning).
A rough test:
```
// REQUIRES: static-analyzer
// RUN: clang-tidy -checks='-*,bugprone-unhandled-self-assignment' %s -- | FileCheck %s
namespace std {
namespace pmr {
template
class allocator {};
}
struct allocator_arg_t {} allocator_arg;
};
#define LEADING_STYLE 1
class MyValueType
{
// pointer member to trigger bugprone-unhandled-self-assignment
void *foo = nullptr;
public:
using allocator_type = std::pmr::allocator<>;
MyValueType(const MyValueType& other)
{
}
#ifdef LEADING_STYLE
MyValueType(std::allocator_arg_t, const allocator_type& alloc, const MyValueType& other)
{
}
#else
MyValueType(const MyValueType& other, const allocator_type& alloc)
{
}
#endif
#ifdef LEADING_STYLE
// CHECK-NOT: warning
MyValueType& operator=(const MyValueType& other)
{
MyValueType tmp(std::allocator_arg, get_allocator(), other);
swap(tmp);
return *this;
}
#else
// CHECK-NOT: warning
MyValueType& operator=(const MyValueType& other)
{
MyValueType tmp(other, get_allocator());
swap(tmp);
return *this;
}
#endif
void swap(MyValueType& other) noexcept {
}
allocator_type get_allocator() const {
return allocator_type();
}
};
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146317] [clang-format] Incorrect Formatting Between clang-format off and clang-format on
Issue
146317
Summary
[clang-format] Incorrect Formatting Between clang-format off and clang-format on
Labels
clang-format
Assignees
Reporter
rocfu
### Title: Incorrect Formatting Between clang-format off and clang-format on
Here is a snippet of isolated and formatted C++ code, but in my configuration, it causes the section between "clang-format off" and "clang-format on" to be formatted. It seems that the SeparateDefinitionBlocks option doesn't prevent formatting and still triggers it before the // clang-format on section.
```cpp
// clang-format off
void function()
{
}
// clang-format on
```
The formatting result adds an extra line between the function and the // clang-format on comment:
```cpp
// clang-format off
void function()
{
}
// clang-format on
```
My environment:
* clang-format version 17.0.6 and version 18.1.4
.clang-format configuration:
```
Language: Cpp
SeparateDefinitionBlocks: Always
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146407] [RISCV] Code Size Increase on SPEC with -mcpu=spacemit-x60 caused by PR 144564
Issue
146407
Summary
[RISCV] Code Size Increase on SPEC with -mcpu=spacemit-x60 caused by PR 144564
Labels
new issue
Assignees
Reporter
mikhailramalho
This is an issue to track the code size regression caused by the scheduling model changes, from PR #144564.
The results: https://lnt.lukelau.me/db_default/v4/nts/674?compare_to=673
After updating SpacemiT X60 scheduling model with hardware-measured latencies, the code size increased due to extra vector register spills. The following reduced test from Blender shows the issue:
```
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "riscv64-unknown-linux-gnu"
define fastcc @do_cross_effect_byte(ptr %rect2, i16 %0, i16 %1, %2) {
entry:
%3 = insertelement zeroinitializer, i16 %1, i64 0
%4 = shufflevector %3, zeroinitializer, zeroinitializer
%5 = insertelement zeroinitializer, i16 %0, i64 0
%strided.vec142 = tail call { , , , } @llvm.vector.deinterleave4.nxv64i8( zeroinitializer)
%6 = extractvalue { , , , } %strided.vec142, 0
%7 = extractvalue { , , , } %strided.vec142, 1
%8 = extractvalue { , , , } %strided.vec142, 2
%9 = extractvalue { , , , } %strided.vec142, 3
%10 = zext %6 to
%11 = mul %4, %10
%wide.vec143 = load , ptr %rect2, align 1
%strided.vec144 = tail call { , , , } @llvm.vector.deinterleave4.nxv64i8( %wide.vec143)
%12 = extractvalue { , , , } %strided.vec144, 0
%13 = extractvalue { , , , } %strided.vec144, 1
%14 = extractvalue { , , , } %strided.vec144, 2
%15 = extractvalue { , , , } %strided.vec144, 3
%16 = zext %12 to
%17 = mul %2, %16
%18 = add %17, %11
%19 = trunc %18 to
%20 = zext %7 to
%21 = mul %4, %20
%22 = zext %13 to
%23 = mul %2, %22
%24 = add %23, %21
%25 = trunc %24 to
%26 = zext %8 to
%27 = mul %4, %26
%28 = zext %14 to
%29 = mul %2, %28
%30 = add %29, %27
%31 = trunc %30 to
%32 = zext %9 to
%33 = mul %4, %32
%34 = zext %15 to
%35 = mul %5, %34
%36 = add %35, %33
%37 = trunc %36 to
%interleaved.vec145 = tail call @llvm.vector.interleave4.nxv64i8( %19, %25, %31, %37)
ret %interleaved.vec145
}
; Function Attrs: nocallback nofree nosync nounwind willreturn memory(none)
declare { , , , } @llvm.vector.deinterleave4.nxv64i8() #0
; Function Attrs: nocallback nofree nosync nounwind willreturn memory(none)
declare @llvm.vector.interleave4.nxv64i8(, , , ) #0
; uselistorder directives
uselistorder ptr @llvm.vector.deinterleave4.nxv64i8, { 1, 0 }
attributes #0 = { nocallback nofree nosync nounwind willreturn memory(none) }
```
After the patch, we start to see extra `vs4r.v` and `vl4r.v`.
While debugging the issue, I've tried a couple of things:
1. Increase the latency of vector ld/st instructions: **Didn't fix the issue**. Even going as high as 1000 cycles of latencies doesn't change the final generated code.
2. Adding ReleaseAtCycle to all vector integer instructions, which scales with LMUL: **it fixes the issue**. I'm investigating why. I got this idea from looking at the P400 scheduling model.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146362] [Flang] Preprocessor
Issue 146362 Summary [Flang] Preprocessor Labels flang Assignees Reporter marikurz-amd I encountered 3 problems with the Flang preprocessor that give unexpected results that do not match the output of the Intel, GNU or Cray Fortran compilers. The following gives a reproducer and details for each of them. Each code snippet is compiled with: ```bash flang -cpp -o demonstrator demonstrator.f90 && ./demonstrator ``` using ``` flang version 21.0.0git (https://github.com/llvm/llvm-project 532facc78e075255afde69f2d86f26e4d4dd4c7f) Target: x86_64-unknown-linux-gnu ``` ### Bug 1: Compiling the following code: ```fortran #define UNITY(k) 1_ ## k PROGRAM REPRODUCER WRITE(*,*) UNITY(4) END PROGRAM REPRODUCER ``` causes a core dump in the preprocessing stage. The expected output would be to just print a `1` to standard out (intel, Cray compiler) or throw an compilation error (GNU) since `1_` is not a parsable token. In no case it should crash. ### Bug 2: The following demonstrator reveals a problem in a composite truth evaluation: ```fortran PROGRAM Demonstrator #if 1 WRITE(*,*) '`1` evaluates to TRUE' #else WRITE(*,*) '`1` evaluates to FALSE' #endif #if 2 WRITE(*,*) '`2` evaluates to TRUE' #else WRITE(*,*) '`2` evaluates to FALSE' #endif #if (1 && 2) WRITE(*,*) '`1 && 2` evaluates to TRUE' #else WRITE(*,*) '`1 && 2` evaluates to FALSE' #endif END PROGRAM Demonstrator ``` The program outputs: ``` `1` evaluates to TRUE `2` evaluates to TRUE `1 && 2` evaluates to FALSE ``` even though both values individually evaluate to `TRUE`. The generated preprocessed file looks like (empty lines removed): ```fortran #line "./demonstrator.f90" 1 PROGRAM Demonstrator WRITE(*,*) '`1` evaluates to TRUE' WRITE(*,*) '`2` evaluates to TRUE' WRITE(*,*) '`1 && 2` evaluates to FALSE' END PROGRAM Demonstrator ``` The expected output (and the one obtained with Intel, GNU, Cray) would be: ``` `1` evaluates to TRUE `2` evaluates to TRUE `1 && 2` evaluates to TRUE ``` ### Bug 3: The token `NUM` is not correctly replaced in the following example: ```fortran #define NUM 1 PROGRAM Reproducer IMPLICIT NONE ! This compiles WRITE(*,*) & NUM ! This does also compile WRITE(*,*) (& 1,NUM ) ! This does NOT compile WRITE(*,*) (& NUM ) END PROGRAM Reproducer ``` The preprocessed output yields (empty lines removed) ```fortran #line "./demonstrator.f90" 2 PROGRAM Reproducer IMPLICIT NONE WRITE(*,*) 1 WRITE(*,*)( 1,1) WRITE(*,*)( NUM) END PROGRAM Reproducer ``` The final `NUM` does not get replaced due to the newline and the brackets, causing the compilation to fail, since `NUM` is not defined. Ifort, Gfortran and Cray-Fortran all compile this code and yield something like this in the output: ``` 1 (1.,1.) 1 ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146351] [c23] `typeof(type-name)` in enumeration fixed underlying type is broken
Issue
146351
Summary
[c23] `typeof(type-name)` in enumeration fixed underlying type is broken
Labels
new issue
Assignees
Reporter
MisterDA
Setting a `typeof(type-name)` in an enumeration fixed underlying type is broken: an error is raised explaining that the identifiers are not declared, but we're in the process of declaring them. The bug is present in clang 20.1.0. GCC 15.1 doesn't have this bug.
See C23 6.7.3.6.p4 Typeof specifiers
> If the `typeof` operators are applied to an _expression_, they yield the type of their operand. Otherwise, they designate the same type as the type name with any nested `typeof` specifier evaluated.
Interestingly, `typeof(_expression_)` isn't broken!
https://gcc.godbolt.org/z/TGWYdhndo
```c
enum e : int {
E = 0,
};
enum f : typeof(int) {
F = 0, /* error: use of undeclared identifier 'F' */
};
int g = 0;
enum g : typeof(g) {
G = 0,
};
int main() {}
```
```
:6:5: error: use of undeclared identifier 'F'
6 | F = 0,
| ^
1 error generated.
Compiler returned: 1
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146401] Clang does not recognize hand-written buffer aliasing checks
Issue 146401 Summary Clang does not recognize hand-written buffer aliasing checks Labels clang Assignees Reporter davidben Clang (and GCC) don't seem to recognize the `__fh_overlap` macro in https://godbolt.org/z/EqjKe716r as a buffer aliasing check. The sample was adapted from https://github.com/jvoisin/fortify-headers/blob/master/include/string.h, which is reportedly used in Musl-based Linux distributions like Alpine. In this case, since `r` was just allocated, the compiler should be able to reason that `r` cannot overlap with `a` and delete the `__fh_overlap` check. It's also important to be able to optimize this because `memcpy` is the usual pattern to load memory without tripping strict aliasing issues. CC @andres-erbsen ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146376] Request Commit Access For Jad_dyen
Issue 146376 Summary Request Commit Access For Jad_dyen Labels infra:commit-access-request Assignees Reporter Jaddyen I will be working on adding `mlir` models to llvm to enhance AOT compilation. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146377] Wrong warning generated (gcc works OK)
Issue
146377
Summary
Wrong warning generated (gcc works OK)
Labels
new issue
Assignees
Reporter
socketpair
The following code is pretty correct, but Clang emits warning. I consider it a bug.
```cpp
struct X {
int x_field{};
};
struct Y {
template
Y() : y_field(x.x_field) {}
X x;
int y_field;
};
```
https://godbolt.org/z/Y4Y7nMnTM
x86-64 clang (trunk) -O3 -std=c++20 -Wall -Wextra :
```
:7:19: warning: field 'x' is uninitialized when used here [-Wuninitialized]
7 | Y() : y_field(x.x_field) {}
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146387] [objective-c][c++] Segfault in CodeGen when calling [super test] inside a C++ lambda with GCC ObjC runtime
Issue
146387
Summary
[objective-c][c++] Segfault in CodeGen when calling [super test] inside a C++ lambda with GCC ObjC runtime
Labels
new issue
Assignees
Reporter
bonsthie
will working on the clang test suite [clang/test/CodeGenObjCXX/lambda-expressions.mm](https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGenObjCXX/lambda-expressions.mm)
i got a compiler segfault when compiling it with the default driver:
```bash
clang lambda-expressions.mm -fblocks
```
i narrowed it down to using an Objective-C `super` call inside a C++ lambda on the GCC runtime path and with the verifier disabled:
```bash
clang -cc1 \
-disable-llvm-verifier \
-fobjc-runtime=gcc \
-emit-obj lambda-expressions.mm
```
### source file:
```cpp
template void take_lambda(T &&lambda) { lambda(); }
@interface A
- (void)test;
@end
@interface B : A
@end
@implementation B
- (void)test {
take_lambda([=] { [super test]; });
}
@end
```
### environment:
```bash
clang version 20.1.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/15.1.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.1.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
```
### Expected behavior
```bash
Aliasee cannot be NULL!
ptr @.objc_class_refB
fatal error: error in backend: Broken module found, compilation aborted!
```
### stack trace
```bash
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 -cc1 test_lambda_segfault.mm -disable-llvm-verifier -fobjc-runtime=gcc -emit-obj
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test_lambda_segfault.mm'.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@"_ZZ10_i_B__testENK3$_0clEv"'
#0 0x7fabab2ea01d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/src/debug/llvm/llvm-20.1.6.src/lib/Support/Unix/Signals.inc:799:22
#1 0x7fabab2e7647 llvm::sys::RunSignalHandlers() /usr/src/debug/llvm/llvm-20.1.6.src/lib/Support/Signals.cpp:105:20
#2 0x7fabab2e7647 SignalHandler /usr/src/debug/llvm/llvm-20.1.6.src/lib/Support/Unix/Signals.inc:405:31
#3 0x7fabaa44def0 (/usr/lib/libc.so.6+0x3def0)
#4 0x7fabab4639d6 llvm::Value::getValueID() const /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/IR/Value.h:533:12
#5 0x7fabab4639d6 llvm::GlobalObject::classof(llvm::Value const*) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/IR/GlobalObject.h:161:25
#6 0x7fabab4639d6 llvm::isa_impl::doit(llvm::Constant const&) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:64:64
#7 0x7fabab4639d6 llvm::isa_impl_cl::doit(llvm::Constant const*) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:110:36
#8 0x7fabab4639d6 llvm::isa_impl_wrap::doit(llvm::Constant const* const&) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:137:41
#9 0x7fabab4639d6 llvm::isa_impl_wrap::doit(llvm::Constant const* const&) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:129:13
#10 0x7fabab4639d6 llvm::CastIsPossible::isPossible(llvm::Constant const* const&) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:257:62
#11 0x7fabab4639d6 llvm::CastInfo::doCastIfPossible(llvm::Constant const* const&) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:493:26
#12 0x7fabab4639d6 decltype(auto) llvm::dyn_cast(llvm::Constant const*) /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/Support/Casting.h:663:48
#13 0x7fabab4639d6 findBaseObject > /usr/src/debug/llvm/llvm-20.1.6.src/lib/IR/Globals.cpp:365:40
#14 0x7fabab469f6b llvm::DenseMap, llvm::detail::DenseSetPair>::~DenseMap() /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/ADT/DenseMap.h:766:50
#15 0x7fabab469f6b llvm::detail::DenseSetImpl, llvm::detail::DenseSetPair>, llvm::DenseMapInfo>::~DenseSetImpl() /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/ADT/DenseSet.h:54:7
#16 0x7fabab469f6b llvm::DenseSet>::~DenseSet() /usr/src/debug/llvm/llvm-20.1.6.src/include/llvm/ADT/DenseSet.h:274:7
#17 0x7fabab469f6b llvm::GlobalValue::getAliaseeObject() const /usr/src/debug/llvm/llvm-20.1.6.src/lib/IR/Globals.cpp:403:1
#18 0x7fabae210fbd llvm::TargetMachine::isLargeGlobalValue(llvm::GlobalValue const*) const /usr/src/debug/llvm/llvm-20.1.6.src/lib/Target/TargetMachine.cpp:56:3
#19 0x7fabafe17d4b handleConstantAddresses /usr/src/debug/llvm/llvm-20.1.6.src/lib/T
[llvm-bugs] [Bug 146389] FP/Int uops breakdown is missing from llvm-exegesis uop decomposition on Zen2
Issue
146389
Summary
FP/Int uops breakdown is missing from llvm-exegesis uop decomposition on Zen2
Labels
new issue
Assignees
Reporter
TiborGY
Running exegesis uop decomposition on Zen2 yields only the Zn2AGU and Zn2Divider, and what I assume is the total number of uops across all execution units, including the FPU and the Int units.
Assuming the HW is capable of measuring these things, exegesis should implement measuring Int and FP uops on Zen2.
```
./llvm-exegesis -mode=uops -opcode-name=VEXTRACTF128rri -mcpu=znver2 --benchmark-repeat-count=10
---
mode:uops
key:
instructions:
- 'VEXTRACTF128rri XMM4 YMM5 i_0x1'
config: ''
register_initial_values:
- 'YMM5=0x0'
cpu_name: znver2
llvm_triple: x86_64-unknown-linux-gnu
min_instructions: 1
measurements:
- { key: Zn2AGU, value: 0.0069, per_snippet_value: 0.0069, validation_counters: {} }
- { key: Zn2Divider, value: 0, per_snippet_value: 0, validation_counters: {} }
- { key: NumMicroOps, value: 1.0148, per_snippet_value: 1.0148, validation_counters: {} }
error: ''
info:instruction has no tied variables, avoiding Read-After-Write issue, picking random def and use registers not aliasing each other, for uses, reusing the same register for all positions
assembled_snippet: 4883EC20C70424C7442404C7442408C744240CC7442410C7442414C7442418C744241CC5FE6F2C244883C420C4E37D19EC01C4E37D19EC01C4E37D19EC01C4E37D19EC01C3
...
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146392] [clang] Assertion `!isResultDependent() && "Generic selection is result-dependent but getResultIndex called!"' failed
Issue 146392 Summary [clang] Assertion `!isResultDependent() && "Generic selection is result-dependent but getResultIndex called!"' failed Labels clang Assignees Reporter dmantipov Triggered by clang-tidy (HEAD at 629126ed44bd3ce5b6f476459c805be4e4e0c2ca), crash [test5.log](https://github.com/user-attachments/files/20984723/test5.log) and C reproducer [test5.txt](https://github.com/user-attachments/files/20984722/test5.txt). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146393] [NFC][HLSL] Move resource range logic from `SemaHLSL` to `RootSignatureValidations`
Issue 146393 Summary [NFC][HLSL] Move resource range logic from `SemaHLSL` to `RootSignatureValidations` Labels HLSL Assignees inbelic Reporter inbelic This issue tracks the work to abstract out the logic of detecting resource range overlap from `SemaHLSL` into the `RootSignatureValidations` library. This logic includes the detection of if the `ResourceClass`, `space` and `visibility` are overlapping and thus the underlying ranges overlap contained in the `handleHLSLRootSignatureDecl` function [here](https://github.com/llvm/llvm-project/blob/de7c2f29405ff08a91a34bc0f152cfa1cd0d9801/clang/lib/Sema/SemaHLSL.cpp#L1080). This is a non-functional change, but it will require a slight change to the `RangeInfo` structure such that each `RangeInfo` can be mapped back to its `RootElement`. The proposed solution is to use an `Index` on each `RangeInfo` that will retain this. AC: - [ ] Update `RangeInfo` to have an `Index` field that can be used to map back to its relevant diagnostic information - [ ] Move the validation logic from `SemaHLSL` to `RootSignatureValidations` - [ ] Update `SemaHLSL` to use the new interface for the validations ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146428] _fltused reference generated for vector floating point operations
Issue
146428
Summary
_fltused reference generated for vector floating point operations
Labels
new issue
Assignees
Reporter
AdamGlass
This is a MSVC-compatibility issue and relates only to that environent.
We've observed references to_ fltused being issued due to the presence of vector floating point operations.
* According to the MSVC folks, a reference to fltused should be issued in the presence of floating point types, not vectors. The whole fltused thing may precede the existence of vectors :).
* By inspection, the CRT code invoked by referencing fltused fills in a table of handlers used by the CRT related to floating point value conversions to strings, removing trailing zeros from floating point output, ascii to float conversion, etc and locale aware versions. if you ended up in a pathway using these routines without fltused, you should get something like 'floating point not loaded'. Most of the fltused functionality is trying to solve problems similar to the module printf implementation.
* There is some old code related to x86 precision that may also get invoked.
The net is that vectors of floats and operations on them should not trigger the fltused reference and i've confirmed that with MSVC folks. If the code starts to operate on an individual float, then_fltused should get pulled in. There have been some comments previously that this _fltused mechanism was used to prevent vector operation use in the systems code -- that's not accurate.
Demonstration of issue
Code that does loads a vector of floats:
```
#define __MM_MALLOC_H
#include
extern float foo[4];
__m128 func() {
__m128 vector1 = _mm_load_ps(foo);
return vector1;
}
```
This does not generate a reference to fltused on MSVC but does on clang
https://godbolt.org/z/a1v9MdEW7
We see the same behavior with this code:
```
__m128 multiply_vectors(__m128 a, __m128 b) {
return _mm_mul_ps(a, b);
}
```
There is a 2 line fix for this issue that t that will be brought as a PR.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146429] [Clang] -Wformat size_t issues: suggests `%zf` for "broken" namespaced size_t, doesn't recognize `sizeof(...)`
Issue
146429
Summary
[Clang] -Wformat size_t issues: suggests `%zf` for "broken" namespaced size_t, doesn't recognize `sizeof(...)`
Labels
clang
Assignees
Reporter
rprichard
From https://godbolt.org/z/zssKGfhxW (reduced from https://godbolt.org/z/3G6qjb4KT):
```c++
#include
namespace foo4 {
using size_t = unsigned char;
}
namespace foo5 {
using size_t = float;
}
void test_func(unsigned long s) {
// Clang suggests replacing %zu with %zu.
printf("%zu\n", foo4::size_t {});
// Clang suggests replacing %zu with %zf, a nonsensical specifier
printf("%u\n", foo5::size_t {});
// Clang suggests %lu instead of %zu.
printf("%u\n", sizeof(int));
}
```
Maybe `FormatSpecifier::namedTypeToLengthModifier` ought to ignore a type if it's in a namespace?
Alternatively, it could check whether the typedef refers to the expected integer type.
It might be nice if `sizeof(...)` was regarded as "having size_t type" for the purposes of -Wformat.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146442] [SimplifyCFG] Optimization missed to reduce a conditional branch to unconditional
Issue
146442
Summary
[SimplifyCFG] Optimization missed to reduce a conditional branch to unconditional
Labels
new issue
Assignees
Reporter
davidzhengyes
I have created the following test case:
``` llvm
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
; RUN: opt < %s -passes=simplifycfg -S | FileCheck %s
define void @mainfunc(i16 %0) {
; CHECK-LABEL: define void @mainfunc(
; CHECK-SAME: i16 [[TMP0:%.*]]) {
; CHECK-NEXT: [[ENTRY:.*:]]
; CHECK-NEXT:[[TMP1:%.*]] = icmp ugt i16 [[TMP0]], 10
; CHECK-NEXT:br i1 [[TMP1]], label %[[OTHERLOOPEND:.*]], label %[[FOR_BODY_CRITEDGE:.*]]
; CHECK: [[OTHERLOOPEND]]:
; CHECK-NEXT:[[OTHERLOOPIV:%.*]] = call i16 @ivfunc()
; CHECK-NEXT: [[OTHERLOOPPRED:%.*]] = icmp slt i16 [[OTHERLOOPIV]], 100
; CHECK-NEXT: br i1 [[OTHERLOOPPRED]], label %[[OTHERLOOPEND]], label %[[VADDEXIT:.*]]
; CHECK: [[VADDEXIT]]:
; CHECK-NEXT:call void @voidfunc()
; CHECK-NEXT:br label %[[END:.*]]
; CHECK: [[FOR_BODY_CRITEDGE]]:
; CHECK-NEXT:call void @voidfunc()
; CHECK-NEXT:br label %[[FOR_BODY:.*]]
; CHECK: [[FOR_BODY]]:
; CHECK-NEXT:[[IV:%.*]] = phi i16 [ [[IV_NEXT:%.*]], %[[FOR_BODY]] ], [ 0, %[[FOR_BODY_CRITEDGE]] ]
; CHECK-NEXT:[[VAL:%.*]] = tail call <256 x i1> @helperfunc()
; CHECK-NEXT:[[VAL2:%.*]] = tail call <1 x i32> @helperfunc2()
; CHECK-NEXT:[[IV_NEXT]] = add i16 [[IV]], 1
; CHECK-NEXT:[[PRED:%.*]] = icmp slt i16 [[IV_NEXT]], 100
; CHECK-NEXT:br i1 [[PRED]], label %[[FOR_BODY]], label %[[END]]
; CHECK: [[END]]:
; CHECK-NEXT:ret void
;
entry:
br label %otherlooppreheader
otherlooppreheader:
%1 = icmp ugt i16 %0, 10
br i1 %1, label %otherloopend, label %VAddExit
otherloopend:
%otherloopiv = call i16 @ivfunc()
%otherLoopPred = icmp slt i16 %otherloopiv, 100
br i1 %otherLoopPred, label %otherloopend, label %VAddExit
VAddExit:
call void @voidfunc()
br i1 %1, label %end, label %for.body
for.body:
%iv = phi i16 [ %iv.next, %VMulExit ], [ 0, %VAddExit ]
%val = tail call <256 x i1> @helperfunc()
br label %for.body.inner
for.body.inner:
%val2 = tail call <1 x i32> @helperfunc2()
br label %VMulExit
VMulExit:
%iv.next = add i16 %iv, 1
%pred = icmp slt i16 %iv.next, 100
br i1 %pred, label %for.body, label %end
end:
ret void
}
declare i16 @ivfunc()
declare <256 x i1> @helperfunc()
declare <1 x i32> @helperfunc2()
declare void @voidfunc()
```
And it results in the following IR:
``` llvm
; ModuleID = ''
source_filename = ""
define void @mainfunc(i16 %0) {
entry:
%1 = icmp ugt i16 %0, 10
br i1 %1, label %otherloopend, label %for.body.critedge
otherloopend: ; preds = %otherloopend, %entry
%otherloopiv = call i16 @ivfunc()
%otherLoopPred = icmp slt i16 %otherloopiv, 100
br i1 %otherLoopPred, label %otherloopend, label %VAddExit
VAddExit: ; preds = %otherloopend
call void @voidfunc()
br i1 %1, label %end, label %for.body
for.body.critedge: ; preds = %entry
call void @voidfunc()
br label %for.body
for.body: ; preds = %for.body.critedge, %for.body, %VAddExit
%iv = phi i16 [ %iv.next, %for.body ], [ 0, %VAddExit ], [ 0, %for.body.critedge ]
%val = tail call <256 x i1> @helperfunc()
%val2 = tail call <1 x i32> @helperfunc2()
%iv.next = add i16 %iv, 1
%pred = icmp slt i16 %iv.next, 100
br i1 %pred, label %for.body, label %end
end: ; preds = %for.body, %VAddExit
ret void
}
declare i16 @ivfunc()
declare <256 x i1> @helperfunc()
declare <1 x i32> @helperfunc2()
declare void @voidfunc()
```
In the output for.body: block, there is a phi node with three values. If you inspect the rest of the IR, simplifyCFG has simplified the branch in entry (which had otherlooppreheader collapsed into it) to go directly to for.body.critedge because the value is known from the predecessor.
Specifically, the edge with `[ 0, %VAddExit ]` is dead, as VAddExit will only branch to for.body if %1 is false, but in its predecessors, if %1 is false, it would not reach VAddExit anyway. This edge can be removed in this case.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146470] wcschr omits wchar_t from the errors
Issue
146470
Summary
wcschr omits wchar_t from the errors
Labels
new issue
Assignees
Reporter
Alcaro
```c
#include
void the_bug()
{
(void)wcschr(123, 0);
(void)wcsrchr(123, 0);
(void)wcsstr(123, 0);
}
```
C only; the bug does not reproduce in C++, where wchar_t is a keyword. Only specifically wcschr is affected, not even wcsrchr which has identical prototype.
Expected:
```
:5:18: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
:6:19: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
:7:18: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
```
Actual:
```
:5:18: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const int *' [-Wint-conversion]
:6:19: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
:7:18: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
```
https://godbolt.org/z/sdMhhv3d3
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146469] C++: accepts invalid export module
Issue 146469 Summary C++: accepts invalid export module Labels new issue Assignees Reporter pinskia Take: ``` module ; export module unexpanded ; ``` as far I can read [P3034R1](https://wg21.link/P3034R1) this should be invalid as `export module` is handled during preprocessing and https://eel.is/c++draft/cpp#pre-1 gives `module\n;` as being an invalid directive too. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146451] [AVR] llvm-objdump should automatically select the instruction set
Issue
146451
Summary
[AVR] llvm-objdump should automatically select the instruction set
Labels
new issue
Assignees
benshi001
Reporter
benshi001
Given a simple test program:
```c++
int adiw(int a) {
return a + 51;
}
```
Build it with `clang a.c --target=avr -mmcu=avr2 -c -O3`, and then disassemble it with `llvm-objdump -d a.o`, we see
```asm
a.o: file format elf32-avr
Disassembly of section .text:
:
0: c3 96 08 95
```
We must specify `--mcpu=avr2` to `llvm-objdump` explicitly to make `adiw` correctly decoded.
```asm
a.o: file format elf32-avr
Disassembly of section .text:
:
0: c3 96 adiw r24, 0x33
2: 08 95 ret
```
However the generated object file does contain the `avr2` family information.
```bash
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Atmel AVR 8-bit microcontroller
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 284 (bytes into file)
Flags: 0x82, EF_AVR_ARCH_AVR2, relaxable
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 5
Section header string table index: 1
```
So the `llvm-objdump` should automatically select the avr family according to ELF header, other than rely on user's explicit specification.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146327] Request GitHub Issue Triage Permission for Labeling Clang Issues
Issue 146327 Summary Request GitHub Issue Triage Permission for Labeling Clang Issues Labels clang Assignees Reporter Rush10233 Hello! I’m an active reporter and participant in Clang-related issues on GitHub (llvm/llvm-project). I’m now running a fuzzer on the official tests to uncover new bugs. I thought it would be helpful to categorize and handle the bugs more efficiently if I could add the `clang:frontend` and `generated by fuzzer` labels myself when I’m reporting them, so I’d like to request triage permission to apply labels to issues. My GitHub username is: [@Rush10233](https://github.com/Rush10233) Here are some issues I’ve contributed to: [[clang]Crashes when initializing an rvalue reference array of an incomplete class type · Issue #144642 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/issues/144642) [[clang][OpenMP] Crashes with OpenMP `parallel` and `lastprivate` inside template member function · Issue #144302 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/issues/144302) [[clang] Crash with official test `SemaTemplate/instantiate-template-template-parm.cpp` and template alias · Issue #132771 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/issues/132771) [[clang] Crash with official test `Parser/cxx0x-attributes.cpp` and default template argument · Issue #132256 · llvm/llvm-project · GitHub](https://github.com/llvm/llvm-project/issues/132256) I understand the responsibility involved and will use the labeling privilege with care. Please let me know if further information is needed. Thank you! ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146475] [X86][GlobalIsel] Missed optimization for memory access
Issue
146475
Summary
[X86][GlobalIsel] Missed optimization for memory access
Labels
new issue
Assignees
Reporter
mahesh-attarde
Hi
I have small case that produces suboptimal code. In GISEL we dont do memory access contraction as follows.
```
define void @test_float_abs(ptr %argptr) {
%arg = load float, float* %argptr
%abs = tail call float @llvm.fabs.f32(float %arg)
store float %abs, ptr %argptr
ret void
}
```
SDAG
```
*** IR Dump After Module Verifier (verify) ***
define void @test_float_abs(ptr %argptr) {
%arg = load float, ptr %argptr, align 4
%abs = tail call float @llvm.fabs.f32(float %arg)
store float %abs, ptr %argptr, align 4
ret void
}
# *** IR Dump After X86 DAG->DAG Instruction Selection (x86-isel) ***:
%0:gr64 = COPY $rdi
AND8mi %0:gr64, 1, $noreg, 3, $noreg, 127, implicit-def dead $eflags :: (store (s8) into %ir.argptr + 3), (load (s8) from %ir.argptr + 3)
RET 0
# FINAL
test_float_abs: # @test_float_abs
and byte ptr [rdi + 3], 127
ret
```
GISEL
```
test_float_abs: # @test_float_abs
and dword ptr [rdi], 2147483647
ret
```
Please note dword and byte ptr reads on AND.
https://godbolt.org/z/bfoM3qE31
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 146476] [X86][GlobalIsel] In X87, no-sse2, returning floating point halts for SDAG, GISEL behavior differs.
Issue
146476
Summary
[X86][GlobalIsel] In X87, no-sse2, returning floating point halts for SDAG, GISEL behavior differs.
Labels
new issue
Assignees
Reporter
mahesh-attarde
https://godbolt.org/z/9Ejz61Goh
For code with mattr=+87x,-sse2,-sse1
```
define float @test_float_abs(ptr %argptr) {
%arg = load float, float* %argptr
%abs = tail call float @llvm.fabs.f32(float %arg)
ret float %abs
}
```
SDAG
```
error: :0:0: in function test_float_abs float (ptr): SSE register return with SSE disabled
Compiler returned: 1
```
GISEL
```
test_float_abs: # @test_float_abs
mov eax, 2147483647
and eax, dword ptr [rdi]
movdxmm0, eax
ret
```
GISEL lowerreturn consults RETCC and adds xmm0 (Calling Convention) where as DAG does not do that.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
