[llvm-bugs] [Bug 80953] Clang-Tidy: [misc-redundant-expression] false positive for fold expression (...)
Issue 80953 Summary Clang-Tidy: [misc-redundant-_expression_] false positive for fold _expression_ (...) Labels clang-tidy Assignees Reporter HirthammerAllTerra Inspired by [this StackOverflow answer](https://stackoverflow.com/a/71423954), I used C++17 fold expressions to check if all arguments of a variadic template are the same. Therefore, I defined the following template constant: ~~~ cpp template constexpr const bool is_all_same = (... && std::is_same_v); ~~~ Clang-Tidy complains about it as follows: ~~~ error: both sides of operator are equivalent [misc-redundant-_expression_,-warnings-as-errors] constexpr const bool is_all_same = (... && std::is_same_v); ^ error: operator has equivalent nested operands [misc-redundant-_expression_,-warnings-as-errors] constexpr const bool is_all_same = (... && std::is_same_v); ~~~ This should be a false positive if I am not missing anything. Tested it with clang-tidy 15 on Ubuntu 22.04 LTS. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80954] llvm crash: Assertion `Idx >= 0 && "Invalid basic block argument!"' failed.
Issue
80954
Summary
llvm crash: Assertion `Idx >= 0 && "Invalid basic block argument!"' failed.
Labels
new issue
Assignees
Reporter
shao-hua-li
llvm crashes in `loop-idiom` pass.
Bisected to 1c6e6432ca0b6832e06b93a4bcf22ead1899c14d, which was committed by @nikic
Compiler explorer: https://godbolt.org/z/nxhnoE1Mb
**% cat reduced.ll**
```llvm
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @m(i8 %0, i64 %1, i32 %a.promoted) {
entry:
%conv13 = sext i8 %0 to i64
%add14 = add i64 %1, -1
br label %for.cond5thread-pre-split.lr.ph.split.us.us
for.cond5thread-pre-split.lr.ph.split.us.us: ; preds = %for.cond2.loopexit.us.us, %entry
%inc.i1417.us = phi i32 [ %a.promoted, %entry ], [ %inc.i.us20, %for.cond2.loopexit.us.us ]
%add161516.us = phi i64 [ 0, %entry ], [ %add16.us24, %for.cond2.loopexit.us.us ]
br label %for.body7.us.us
for.body7.us.us: ; preds = %for.body7.us.us, %for.cond5thread-pre-split.lr.ph.split.us.us
%2 = phi i64 [ %add9.us.us, %for.body7.us.us ], [ 0, %for.cond5thread-pre-split.lr.ph.split.us.us ]
%arrayidx8.us.us = getelementptr [1 x [5 x i8]], ptr null, i64 0, i64 %add161516.us, i64 %2
store i8 0, ptr %arrayidx8.us.us, align 1
%add9.us.us = add i64 %2, 1
%tobool6.not.us.us = icmp eq i64 %add9.us.us, 0
br i1 %tobool6.not.us.us, label %for.cond2.loopexit.us.us, label %for.body7.us.us
for.cond2.loopexit.us.us: ; preds = %for.body7.us.us
%inc.i.us20 = add nsw i32 %inc.i1417.us, 1
%conv.i.us21 = sext i32 %inc.i1417.us to i64
%add15.us22 = add i64 %add14, %conv.i.us21
%sub.us23 = add i64 %add15.us22, %conv13
%add16.us24 = add i64 %sub.us23, %add161516.us
br label %for.cond5thread-pre-split.lr.ph.split.us.us
}
```
**% opt -disable-output -passes=loop-idiom reduced.ll**
```console
opt: /tmp/tmpxmdtc3mt/tmpn8inmjh2/llvm/include/llvm/IR/Instructions.h:2910: llvm::Value* llvm::PHINode::getIncomingValueForBlock(const llvm::BasicBlock*) const: Assertion `Idx >= 0 && "Invalid basic block argument!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/opt -disable-output -passes=loop-idiom reduced.ll
#0 0x7fc24b876eaf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x914eaf)
#1 0x7fc24b874414 SignalHandler(int) Signals.cpp:0:0
#2 0x7fc24ab77090 (/lib/x86_64-linux-gnu/libc.so.6+0x43090)
#3 0x7fc24ab7700b raise /build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#4 0x7fc24ab56859 abort /build/glibc-wuryBv/glibc-2.31/stdlib/abort.c:81:7
#5 0x7fc24ab56729 get_sysdep_segment_value /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:509:8
#6 0x7fc24ab56729 _nl_load_domain /build/glibc-wuryBv/glibc-2.31/intl/loadmsgcat.c:970:34
#7 0x7fc24ab67fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#8 0x7fc24d68155f llvm::Loop::getCanonicalInductionVariable() const (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x271f55f)
#9 0x7fc24ca39df5 llvm::SCEVExpander::visitAddRecExpr(llvm::SCEVAddRecExpr const*) (.part.0) ScalarEvolutionExpander.cpp:0:0
#10 0x7fc24ca36745 llvm::SCEVVisitor::visit(llvm::SCEV const*) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x1ad4745)
#11 0x7fc24ca3711b llvm::SCEVExpander::expand(llvm::SCEV const*) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x1ad511b)
#12 0x7fc24ca37380 llvm::SCEVExpander::expandCodeForImpl(llvm::SCEV const*, llvm::Type*) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x1ad5380)
#13 0x7fc24ca399ec llvm::SCEVExpander::expandAddToGEP(llvm::SCEV const*, llvm::Type*, llvm::Value*) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x1ad79ec)
#14 0x7fc24ca3ab97 llvm::SCEVExpander::expandIVInc(llvm::PHINode*, llvm::Value*, llvm::Loop const*, llvm::Type*, llvm::Type*, bool) (/zdata/shaoli/compilers/ccbuilder-compilers/clang-1c6e6432ca0b6832e06b93a4bcf22ead1899c14d/bin/../lib/libLLVM-18git.so+0x1ad8b97)
#15 0x7fc24ca3bb6e llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*, llvm::Loop const*, llvm::
[llvm-bugs] [Bug 80957] [llvm-exegesis] Middle half repetition mode test flaky
Issue
80957
Summary
[llvm-exegesis] Middle half repetition mode test flaky
Labels
tools:llvm-exegesis,
new issue
Assignees
boomanaiden154
Reporter
boomanaiden154
The middle half repetition mode test is flaky on the buildbots that run it (https://lab.llvm.org/buildbot/#/builders/258/builds/13464):
```
TEST 'LLVM :: tools/llvm-exegesis/X86/latency/middle-half.s' FAILED
Exit Code: 1
Command Output (stderr):
--
RUN: at line 5: /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/llvm-exegesis -mtriple=x86_64-unknown-unknown -mode=latency -opcode-name=ADD64rr -repetition-mode=middle-half-duplicate | /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/FileCheck /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s
+ /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/FileCheck /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s
+ /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/llvm-exegesis -mtriple=x86_64-unknown-unknown -mode=latency -opcode-name=ADD64rr -repetition-mode=middle-half-duplicate
RUN: at line 6: /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/llvm-exegesis -mtriple=x86_64-unknown-unknown -mode=latency -opcode-name=ADD64rr -repetition-mode=middle-half-loop | /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/FileCheck /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s
+ /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/FileCheck /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s
+ /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/stage1/bin/llvm-exegesis -mtriple=x86_64-unknown-unknown -mode=latency -opcode-name=ADD64rr -repetition-mode=middle-half-loop
/localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s:8:10: error: CHECK: expected string not found in input
# CHECK: - { key: latency, value: {{[0-9.]*}}, per_snippet_value: {{[0-9.]*}}
^
:1:1: note: scanning from here
---
^
:14:2: note: possible intended match here
- { key: latency, value: -0.0024, per_snippet_value: -0.0024, validation_counters: {} }
^
Input file:
Check file: /localdisk2/buildbot/llvm-worker/clang-cmake-x86_64-avx512-linux/llvm/llvm/test/tools/llvm-exegesis/X86/latency/middle-half.s
-dump-input=help explains the following input dump.
Input was:
<<
1: ---
check:8'0 X~~~ error: no match found
2: mode: latency
check:8'0 ~~
3: key:
check:8'0 ~
4: instructions:
check:8'0 ~~~
5: - 'ADD64rr R11 R11 RSI'
check:8'0 ~
6: config: ''
check:8'0
.
.
.
9: - 'RSI=0x0'
check:8'0 ~
10: cpu_name: cascadelake
check:8'0 ~~
11: llvm_triple: x86_64-unknown-unknown
check:8'0
12: min_instructions: 1
check:8'0
13: measurements:
check:8'0 ~~
14: - { key: latency, value: -0.0024, per_snippet_value: -0.0024, validation_counters: {} }
check:8'0 ~
check:8'1 ? possible intended match
15: error: ''
check:8'0 ~~
16: info: Repeating a single implicitly serial instruction
check:8'0 ~~~
17: assembled_snippet: 49BB48BE49B8020066904901F34901F34983C0FF75F4C349BB48BE49B8020066904901F34901F34983C0FF75F4C3
check:8'0
18: ...
check:8'0
>>
--
```
Seems like the negative sign is throwing off the check line. Probably will throw up a quick fix (like setting a retry count) to fix this, but this shouldn't be occurring in the first place and more debugging there will be needed.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
htt
[llvm-bugs] [Bug 80960] Inconsistent results for mlir arith shift operations
Issue
80960
Summary
Inconsistent results for mlir arith shift operations
Labels
mlir
Assignees
Reporter
wangyongj1a
I have the following MLIR program:
test.mlir:
```
func.func @func1() {
%true = arith.constant true
%false = arith.constant false
%c1_i64 = arith.constant 1 : i64
%17 = scf.if %true -> (i1) {
scf.yield %true : i1
} else {
scf.yield %false : i1 // this line can not be changed to %true
}
// can be changed to arith.shli, arith.shrsi and arith.shrui
%22 = arith.shrui %17, %true : i1
%30 = scf.if %true -> (i64) { // this scf.if can not be removed
scf.yield %c1_i64 : i64
} else {
scf.yield %c1_i64 : i64 // but can yield same value.
}
vector.print %22 : i1
return
}
```
The above MLIR program can be lowered and executed using the following commands:
```
mlir-opt --convert-scf-to-cf --convert-cf-to-llvm --convert-vector-to-llvm --convert-arith-to-llvm --convert-func-to-llvm test.mlir > 1.mlir
mlir-translate --mlir-to-llvmir 1.mlir > 2.ll
sed s/@func1/@main/ 2.ll > 3.ll
bin/clang 3.ll lib/libmlir_c_runner_utils.so lib/libmlir_float16_utils.so lib/libmlir_runner_utils.so /usr/lib/gcc/x86_64-linux-gnu/9/libstdc++.so -o out.out
./out.out
```
However, it has inconsistent results over multiple runs.
Is there some problem in the above arith shift operations?
My git version is adbf21f12b3069b2554efb39f2e92c6cf6f24940.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80961] Backport a18e92d to release/18.x
Issue 80961 Summary Backport a18e92d to release/18.x Labels new issue Assignees Reporter Fznamznon Request to backport https://github.com/llvm/llvm-project/pull/80724 . /cherry-pick a18e92d ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80963] Clang fails to detect illegal copy constructor with template class as its parameter
Issue
80963
Summary
Clang fails to detect illegal copy constructor with template class as its parameter
Labels
clang
Assignees
Reporter
Rush10233
The following code is apparently illegal, as the declaration of `A(A)` should be treated as a copy constructor, which forces passing the argument by reference. While clang ignores that error and accepts it:
```c++
template < class T, class V > struct A
{
A ();
A (A &);
A (A < V,T >);
};
void f ()
{
A (A < int, int >());
}
```
Note that if replace `A` with `A` or `A`, the code is still accepted. But when replacing it with `A`, the code is correctly rejected.
Reducing the number of template class arguments to 1 (`template A` and `A(A)`) also makes sense. We suspect the bug will occur only if the template argument list in copy ctor parameter is not identical to that in class declaration.
[https://godbolt.org/z/GKv3E6c4f](https://godbolt.org/z/GKv3E6c4f)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80964] [clang++ crash] while building Chromium 121
Issue 80964 Summary [clang++ crash] while building Chromium 121 Labels clang Assignees Reporter squid-f At about 60% of the build, a crash happens and it is replicable: ``` 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++ -MMD -MF obj/chrome/browser/devtools/devtools/chrome_devtools_session.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE -D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS -DCR_LIBCXX_REVISION=caccdb0407e84357ca6490165e88dcad64e47d17 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_56 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56 -DBASE_USE_PERFETTO_CLIENT_LIBRARY=1 -DSK_ENABLE_SKSL -DSK_UNTIL_CRBUG_1187654_IS_FIXED -DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\" -DSK_WIN_FONTMGR_NO_SIMULATIONS -DSK_DISABLE_LEGACY_SKSURFACE_METHODS -DSK_DISABLE_LEGACY_GRAPHITE_IMAGE_FACTORIES -DSK_DISABLE_LEGACY_GRAPHITE_IMAGE_METHODS -DSK_DISABLE_LEGACY_SKSURFACE_FACTORIES -DSK_DISABLE_LEGACY_SKSURFACE_FLUSH -DSK_DISABLE_LEGACY_SKSURFACE_AS_IMAGE -DSK_DISABLE_LEGACY_SKSURFACE_DISPLAYLIST -DSK_DISABLE_LEGACY_IMAGE_SUBSET_METHODS -DSK_DISABLE_LEGACY_IMAGE_COLORSPACE_METHODS -DSK_DISABLE_LEGACY_IMAGE_RELEASE_PROCS -DSK_DISABLE_LEGACY_GL_BACKEND_SURFACE -DSK_DISABLE_LEGACY_INIT_DECODERS -DSK_DISABLE_LEGACY_GRDIRECTCONTEXT_FLUSH -DSK_DISABLE_LEGACY_GRDIRECTCONTEXT_BOOLS -DSK_DISABLE_LEGACY_GL_GRDIRECTCONTEXT_FACTORIES -DSK_DISABLE_LEGACY_PNG_WRITEBUFFER -DSK_SLUG_DISABLE_LEGACY_DESERIALIZE -DSK_DISABLE_LEGACY_VK_GRDIRECTCONTEXT_FACTORIES -DSK_DEFAULT_TYPEFACE_IS_EMPTY -DSK_CODEC_DECODES_JPEG -DSK_ENCODE_JPEG -DSK_ENCODE_PNG -DSK_ENCODE_WEBP -DSK_GANESH -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DSK_GL -DSK_VULKAN=1 -DSK_GRAPHITE -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR -DLIBYUV_DISABLE_NEON -DUSE_EGL -DTOOLKIT_VIEWS=1 -DON_FOCUS_PING_ENABLED -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DGOOGLE_PROTOBUF_INTERNAL_DONATE_STEAL_INLINE=0 -DHAVE_PTHREAD -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DU_ENABLE_TRACING=1 -DU_ENABLE_RESOURCE_TRACING=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DLEVELDB_PLATFORM_CHROMIUM=1 -DI18N_ADDRESS_VALIDATION_DATA_URL=\"https://chromium-i18n.appspot.com/ssl-aggregate-address/\" -DEIGEN_MPL2_ONLY -DEIGEN_MAX_ALIGN_BYTES=64 -DEIGEN_HAS_TYPE_TRAITS=0 -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -DWEBRTC_ENABLE_AVX2 -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_X11 -DWEBRTC_USE_PIPEWIRE -DWEBRTC_USE_GIO -DLOGGING_INSIDE_WEBRTC -DCRASHPAD_ZLIB_SOURCE_EXTERNAL -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_COMPRESS_POINTERS -DV8_COMPRESS_POINTERS_IN_SHARED_CAGE -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_ENABLE_SANDBOX -DV8_DEPRECATION_WARNINGS -DV8_USE_PERFETTO -DCPPGC_CAGED_HEAP -DCPPGC_YOUNG_GENERATION -DCPPGC_POINTER_COMPRESSION -DCPPGC_SLIM_WRITE_BARRIER -DATK_LIB_DIR=\"/usr/lib64\" -DUSE_ATK_BRIDGE -DOPENSCREEN_TEST_DATA_DIR=\"third_party/openscreen/src/test/data/\" -DENABLE_TRACE_LOGGING -I../.. -Igen -I../../buildtools/third_party/libc++ -I../../third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -I../../net/third_party/quiche/overrides -I../../net/third_party/quiche/src/quiche/common/platform/default -I../../net/third_party/quiche/src -I../../third_party/skia -Igen/third_party/skia -I../../third_party/wuffs/src/release/c -I../../third_party/vulkan/include -I../../third_party/vulkan-deps/vulkan-headers/src/include -I../../third_party/wayland/src/src -I../../third_party/wayland/include/src -Igen/shim_headers/libpng_shim -Igen/shim_headers/libwebp_shim -I../../third_party/libyuv/include -Igen/shim_headers/opus_shim -Igen/shim_headers/ffmpeg_shim -Igen/shim_headers/dav1d_shim -Igen/third_party/dawn/include -I../../third_party/dawn/include -I../../third_party/khronos -I../../gpu -Igen/shim_headers/flac_shim -Igen/third_party/private_membership/src -Igen/third_party/shell-encryption/src -Igen/components/policy/proto -I../../base/allocator/partition_allocator/src -Igen/base/allocator/partition_allocator/src -I../../third_party/abseil-cpp -I../../third_party/boringssl/src/include -I../../third_party/protobuf/src -Igen/protoc_out -I../../third_party/ced/src -I../../third_party/icu/source/comm
[llvm-bugs] [Bug 80971] ICE when explicit object parameter be a function parameter pack
Issue
80971
Summary
ICE when explicit object parameter be a function parameter pack
Labels
new issue
Assignees
Reporter
hewillk
```cpp
struct S {
auto f(this auto self...) { }
};
int main() {
S{}.f(0);
}
```
https://godbolt.org/z/bP8f6hzGs
llvm will crash with the above code, although I'm not sure if the code is well-formed.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80980] [AArch64][SVE] Cannot be vectorized because unsafe dependent memory operation in loop (TSVC, s115)
Issue
80980
Summary
[AArch64][SVE] Cannot be vectorized because unsafe dependent memory operation in loop (TSVC, s115)
Labels
new issue
Assignees
Reporter
m-saito-fj
Clang cannot SVE vectorize TSVC s114, but GCC13.2.0 can.
Option:
`-Ofast -march=armv8.2-a+sve`
```c
#define LEN 32000
#define LEN2 256
static int ntimes = 20;
float a[LEN], b[LEN], c[LEN], d[LEN], e[LEN];
float aa[LEN2][LEN2], bb[LEN2][LEN2], cc[LEN2][LEN2], dd[LEN2][LEN2];
int dummy(float[LEN], float[LEN], float[LEN], float[LEN], float[LEN],
float[LEN2][LEN2], float[LEN2][LEN2], float[LEN2][LEN2], float);
int s115()
{
for (int nl = 0; nl < 1000*(ntimes/LEN2); nl++) {
for (int j = 0; j < LEN2; j++) {
for (int i = j+1; i < LEN2; i++) {
a[i] -= aa[j][i] * a[j];
}
}
dummy(a, b, c, d, e, aa, bb, cc, 0.);
}
return 0;
}
```
See also (Clang vs GCC):
https://godbolt.org/z/h8WE5raja
for.body IR:
```llvm
for.body8.lr.ph: ; preds = %for.body4
%arrayidx12 = getelementptr inbounds [32000 x float], ptr @a, i64 0, i64 %indvars.iv37
br label %for.body8, !dbg !26
for.body8: ; preds = %for.body8.lr.ph, %for.body8
%indvars.iv34 = phi i64 [ %indvars.iv, %for.body8.lr.ph ], [ %indvars.iv.next35, %for.body8 ]
%arrayidx10 = getelementptr inbounds [256 x [256 x float]], ptr @aa, i64 0, i64 %indvars.iv37, i64 %indvars.iv34, !dbg !27
%0 = load float, ptr %arrayidx10, align 4, !dbg !27, !tbaa !28
%1 = load float, ptr %arrayidx12, align 4, !dbg !32, !tbaa !28
%mul13 = fmul fast float %1, %0, !dbg !33
%arrayidx15 = getelementptr inbounds [32000 x float], ptr @a, i64 0, i64 %indvars.iv34, !dbg !34
%2 = load float, ptr %arrayidx15, align 4, !dbg !35, !tbaa !28
%sub = fsub fast float %2, %mul13, !dbg !35
store float %sub, ptr %arrayidx15, align 4, !dbg !35, !tbaa !28
%indvars.iv.next35 = add nuw nsw i64 %indvars.iv34, 1, !dbg !36
%exitcond.not = icmp eq i64 %indvars.iv.next35, 256, !dbg !25
br i1 %exitcond.not, label %for.cond1.loopexit.loopexit, label %for.body8, !dbg !26, !llvm.loop !37
}
```
`-mllvm -debug-_only_=loop-accesses` messages:
```
LAA: Found a runtime check ptr: %arrayidx15 = getelementptr inbounds [32000 x float], ptr @a, i64 0, i64 %indvars.iv34, !dbg !34
LAA: Found a runtime check ptr: %arrayidx12 = getelementptr inbounds [32000 x float], ptr @a, i64 0, i64 %indvars.iv37
LAA: We need to do 0 pointer comparisons.
LAA: May be able to perform a memory runtime check if needed.
LAA: Checking memory dependencies
LAA: Bad stride - Not striding over innermost loop %arrayidx12 = getelementptr inbounds [32000 x float], ptr @a, i64 0, i64 %indvars.iv37 SCEV: {@a,+,4}<%for.body4>
LAA: Src Scev: {@a,+,4}<%for.body4>Sink Scev: {{(4 + @a),+,4}<%for.body4>,+,4}<%for.body8>(Induction step: 0)
LAA: Distance for %1 = load float, ptr %arrayidx12, align 4, !dbg !32, !tbaa !28 to store float %sub, ptr %arrayidx15, align 4, !dbg !35, !tbaa !28: {4,+,4}<%for.body8>
Pointer access with non-constant stride
LAA: Src Scev: {{(4 + @a),+,4}<%for.body4>,+,4}<%for.body8>Sink Scev: {{(4 + @a),+,4}<%for.body4>,+,4}<%for.body8>(Induction step: 1)
LAA: Distance for %2 = load float, ptr %arrayidx15, align 4, !dbg !35, !tbaa !28 to store float %sub, ptr %arrayidx15, align 4, !dbg !35, !tbaa !28: 0
Total Dependences: 2
LAA: unsafe dependent memory operations in loop
```
There seems to be a problem with the two dependencies.
1) Load and store for a[i]
2) Store for a[i] and load for a[j]
GCC13 is able to vectorize by vector masked load/store.
```asm
.L4:
ld1wz1.s, p0/z, [x8, x0, lsl 2]
ld1wz0.s, p0/z, [x10, x0, lsl 2]
fmsbz0.s, p1/m, z2.s, z1.s
st1wz0.s, p0, [x8, x0, lsl 2]
add x0, x0, x20
whilelo p0.s, w0, w9
b.any .L4
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80981] Inconsistent indentation
Issue
80981
Summary
Inconsistent indentation
Labels
Assignees
Reporter
HFriberg
When I format
```c
#ifdef __cplusplus
extern "C"
{
#endif
#if 0
typedef int myint;
typedef double mydouble;
#endif
#if 1
#else
typedef int myint2;
typedef double mydouble2;
#endif
typedef int myint3;
typedef double mydouble3;
#ifdef __cplusplus
} /* extern "C" */
#endif
```
I get
```c
#ifdef __cplusplus
extern "C"
{
#endif
#if 0
typedef int myint;
typedef double mydouble;
#endif
#if 1
#else
typedef int myint2;
typedef double mydouble2;
#endif
typedef int myint3;
typedef double mydouble3;
#ifdef __cplusplus
} /* extern "C" */
#endif
```
1) Why is formatting inactive in the `#if 0` block, but active in the `#if 1 ... #else` block?
2) Why is the indentation of `myint2` and `mydouble2` inconsistent with the indentation of `myint3` and `mydouble3`?
---
My `.clang-format` style is
```
BasedOnStyle: LLVM
BreakBeforeBraces: Allman
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80982] [OMPT] Ident wrong ident flags with distributed parallel for
Issue
80982
Summary
[OMPT] Ident wrong ident flags with distributed parallel for
Labels
new issue
Assignees
Reporter
mikaoP
```c
// t1.c
#include
#include
int main(void)
{
#pragma omp teams
{
#pragma omp distribute parallel for
for (volatile int i = 0; i < 100; i++);
}
}
```
```c
// tool.c
#include
#include
#include
static ompt_set_callback_t ompt_set_callback;
#define register_ompt_callback_t(name, type) \
do { \
type f_##name = &on_##name; \
if (ompt_set_callback(name, (ompt_callback_t)f_##name) == ompt_set_never) \
printf("0: Could not register callback '" #name "'\n"); \
} while (0)
#define register_ompt_callback(name) register_ompt_callback_t(name, name##_t)
static void
on_ompt_callback_work(
ompt_work_t wstype,
ompt_scope_endpoint_t endpoint,
ompt_data_t *parallel_data,
ompt_data_t *task_data,
uint64_t count,
const void *codeptr_ra)
{
switch(endpoint)
{
case ompt_scope_begin:
printf("begin ");
switch(wstype)
{
case ompt_work_loop:
printf("ompt_work_loop\n");
break;
case ompt_work_loop_static:
printf("ompt_work_loop_static\n");
break;
case ompt_work_loop_dynamic:
printf("ompt_work_loop_dynamic\n");
break;
case ompt_work_loop_guided:
printf("ompt_work_loop_guided\n");
break;
case ompt_work_loop_other:
printf("ompt_work_loop_other\n");
break;
case ompt_work_sections:
printf("ompt_work_sections\n");
break;
case ompt_work_single_executor:
printf("ompt_work_single_executor\n");
break;
case ompt_work_single_other:
printf("ompt_work_single_other\n");
break;
case ompt_work_workshare:
printf("ompt_work_workshare\n");
break;
case ompt_work_distribute:
printf("ompt_work_distribute\n");
break;
case ompt_work_taskloop:
printf("ompt_work_taskloop\n");
break;
case ompt_work_scope:
printf("ompt_work_scope\n");
break;
}
break;
case ompt_scope_end:
printf("end ");
switch(wstype)
{
case ompt_work_loop:
printf("ompt_work_loop\n");
break;
case ompt_work_loop_static:
printf("ompt_work_loop_static\n");
break;
case ompt_work_loop_dynamic:
printf("ompt_work_loop_dynamic\n");
break;
case ompt_work_loop_guided:
printf("ompt_work_loop_guided\n");
break;
case ompt_work_loop_other:
printf("ompt_work_loop_other\n");
break;
case ompt_work_sections:
printf("ompt_work_sections\n");
break;
case ompt_work_single_executor:
printf("ompt_work_single_executor\n");
break;
case ompt_work_single_other:
printf("ompt_work_single_other\n");
break;
case ompt_work_workshare:
printf("ompt_work_workshare\n");
break;
case ompt_work_distribute:
printf("ompt_work_distribute\n");
break;
case ompt_work_taskloop:
printf("ompt_work_taskloop\n");
break;
case ompt_work_scope:
printf("ompt_work_scope\n");
break;
}
break;
case ompt_scope_beginend:
printf("ompt_scope_beginend should never be passed to %s\n", __func__);
exit(-1);
}
}
void ompt_finalize(ompt_data_t *tool_data)
{
printf("0: ompt_event_runtime_shutdown\n");
}
int ompt_initialize(
ompt_function_lookup_t lookup,
int initial_device_num,
ompt_data_t *tool_data)
{
ompt_set_callback = (ompt_set_callback_t) lookup("ompt_set_callback");
register_ompt_callback(ompt_callback_work);
printf("0: NULL_POINTER=%p\n", (void*)NULL);
return 1; //success
}
ompt_start_tool_result_t *ompt_start_tool(
unsigned int omp_version,
const char *runtime_version
){
static ompt_start_tool_result_t ompt_start_tool_result = {&ompt_initialize,&ompt_finalize, 0};
return &ompt_start_tool_result;
}
```
Compile and run: `clang -fopenmp t1.c && clang -fopenmp tool.c -shared -fPIC -o libtool.so && OMP_NUM_THREADS=2 OMP_TOOL_LIBRARIES=$PWD/libtool.so ./a.out`
Gives the following output
```
begin ompt_work_distribute
begin ompt_work_loop
end ompt_work_distribute
begin ompt_work_loop
end ompt_work_distribute
end ompt_work_distribute
```
There is a mismatch between the `work_loop` and the `work_distribute` flag. The reason is that in clang's codegen it is not possible to determine which of the to worksharings are being built in the `emitForStaticFinish` function. Since `work_distribute` has preference in a combined pragma, all events show it.
___
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 #3 on issue 65993 by ClusterFuzz-External: llvm: Fuzzing build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65993#c3 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-5585c00c-f3fa-4b8e-a077-1ff1a57f4cdb.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 80992] [BOLT] perf2bolt fails on aarch64 due to an unsupported CFI opcode
Issue 80992 Summary [BOLT] perf2bolt fails on aarch64 due to an unsupported CFI opcode Labels BOLT Assignees Reporter ARG-NK I am using BOLT to optimize a binary compiled with GCC (used options -gdwarf64 and -gdwarf4 ): When perf2bolt is used I get the below error message: command: perf2bolt -p perf.data FILENAME.so -o perf.fdata --itrace=el64i10ns  This is the opcode:  does BOLT support binary with dwarf64 format ? ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80997] lambda with `this auto` that captures `this` in a member function is not an integral constant expression
Issue
80997
Summary
lambda with `this auto` that captures `this` in a member function is not an integral constant _expression_
Labels
new issue
Assignees
Reporter
hewillk
https://godbolt.org/z/azqxac8xE
```cpp
struct S {
int i = 42;
constexpr auto f() {
return [this](this auto) {
return this->i;
}();
};
};
static_assert(S().f() == 42);
```
Clang rejects the above code with:
```
:10:15: error: static assertion _expression_ is not an integral constant _expression_
10 | static_assert(S().f() == 42);
| ^
:5:14: note: use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function
5 | return this->i;
| ^
```
If we remove `this auto` then [compile fine](https://godbolt.org/z/Gb8qE7Whh), the two should be equivalent right?
Not really sure what the standards say about this.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 80999] test-release.sh ninja install does builds in Phase 3
Issue 80999 Summary test-release.sh ninja install does builds in Phase 3 Labels new issue Assignees tstellar Reporter rorth When running `test-release.sh` on Linux/sparc64 (although this happens everywhere), I noticed that in Phase3, `ninja install` actually does builds. This is unexpected, and made way worse because it passes on neither `-j` options nor `-v`, so you cannot see what actually happens. Missing the `-j` even badly broke the Linux/sparc64 build which is on a somewhat resource-constrained system. For that reason, the build is run with `-j12` while the system has 24 cores. When it comes to Phase3, however, a large part of the build (`flang` in particular) is run with the full parallelism, which totally overwhelms the memory resources of the system and ultimately causes the build to fail. `flang` has always been sort of nightmare on every system because the source files are quite big and compilation way more memory intensive than every other part of LLVM. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81000] Backport 16a1ef86cbc5e6c829919ec6c73325413b0cd21b to release/18.x
Issue 81000 Summary Backport 16a1ef86cbc5e6c829919ec6c73325413b0cd21b to release/18.x Labels compiler-rt, compiler-rt:sanitizer Assignees Reporter DimitryAndric This removes `hexdump` interception, which was unnecessary. /cherry-pick 16a1ef86cbc5e6c829919ec6c73325413b0cd21b ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81001] [clang-tidy] New check: Prefer list initialization
Issue 81001 Summary [clang-tidy] New check: Prefer list initialization Labels enhancement, clang-tidy Assignees Reporter SunBlack We are currently still using round brackets instead of curly brackets to create instances in our project. The transition within the member initialization lists to list initialization already showed some type issues. As showed e.g., [here](https://stackoverflow.com/a/18222927) I think there are good reasons to prefer list initialization. Sadly it is not possible to refactor a project just with regular expressions, as there are some exceptions. So my suggestion is to: - Add a check `modernize-use-list-initialization` (ways thinking also about `bugprone` category, but not sure which is better) - Suggest list initialization on all objects, which doesn't implement a initialization list constructor (e.g., `std::vector` should not transformed to an initializer list). ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81012] fatal error: error in backend: Do not know how to split this operator's operand! when compiling qtwebengine-6.6.1 with clang 17.0.6 on x86_64
Issue 81012 Summary fatal error: error in backend: Do not know how to split this operator's operand! when compiling qtwebengine-6.6.1 with clang 17.0.6 on x86_64 Labels clang Assignees Reporter gcarq When compiling `dev-qt/qtwebengine-6.6.1` on Gentoo with a systemwide clang/libcxx profile, clang++ fails with exit code 70. No special CXXFLAGS are passed besides `-ftrapping-math -fsemantic-interposition -ffp-contract=fast` to mimic gccs default behaviour. ``` Stack dump: 0. Program arguments: /usr/lib/llvm/17/bin/clang++ -MMD -MF obj/skia/skia_opts_hsw/SkOpts_hsw.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DSK_CODEC_DECODES_PNG -DSK_CODEC_DECODES_WEBP -DSK_ENCODE_PNG -DSK_ENCODE_WEBP -DSK_ENABLE_SKSL -DSK_UNTIL_CRBUG_1187654_IS_FIXED -DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\" -DSK_WIN_FONTMGR_NO_SIMULATIONS -DSK_GL -DSK_CODEC_DECODES_JPEG -DSK_ENCODE_JPEG -DSK_HAS_WUFFS_LIBRARY -DSK_VULKAN=1 -DSK_SUPPORT_GPU=1 -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DVK_USE_PLATFORM_XCB_KHR -DIS_SKIA_IMPL=1 -DSKIA_IMPLEMENTATION=1 -DSK_TYPEFACE_FACTORY_FREETYPE -DSK_GAMMA_EXPONENT=1.2 -DSK_GAMMA_CONTRAST=0.2 -DSK_DEFAULT_FONT_CACHE_LIMIT=20971520 -Igen -I../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium -I../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/skia -I../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/wuffs/src/release/c -I../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/vulkan/include -I../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/vulkan-deps/vulkan-headers/src/include -march=native -O3 -pipe -O2 -ftrapping-math -fsemantic-interposition -ffp-contract=fast -mavx2 -mbmi -mbmi2 -mf16c -mfma -fno-delete-null-pointer-checks -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-unknown-argument -Wno-unknown-attributes -Wno-unknown-warning-option -Wno-predefined-identifier-outside-function -Wno-unknown-pragmas -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -m64 -msse3 -no-canonical-prefixes -fno-omit-frame-pointer -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-unused-but-set-variable -Wno-misleading-indentation -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wenum-compare-conditional -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -Wno-parentheses-equality -Wno-tautological-compare -Wno-thread-safety-attributes -Wno-undefined-bool-conversion -Wno-tautological-undefined-compare -std=c++20 -Wno-trigraphs -gsimple-template-names -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -c ../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/skia/src/opts/SkOpts_hsw.cpp -o obj/skia/skia_opts_hsw/SkOpts_hsw.o 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '../../../../../qtwebengine-everywhere-src-6.6.1/src/3rdparty/chromium/third_party/skia/src/opts/SkOpts_hsw.cpp'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_ZN3hsw14interpret_skvmEPKN4skvm22InterpreterInstructionEiiiPKiPPNS0_9TraceHookEiiiPPv' #0 0x7f12b45d7c06 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3dd7c06) #1 0x7f12b45d52e0 llvm::sys::RunSignalHandlers() (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3dd52e0) #2 0x7f12b44fddfe (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3cfddfe) #3 0x7f12b44fddbb (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3cfddbb) #4 0x7f12b45d1589 (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3dd1589) #5 0x55b8c1449bb1 (/usr/lib/llvm/17/bin/clang+++0x15bb1) #6 0x7f12b4510c0e llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3d10c0e) #7 0x7f12b4510ab7 llvm::report_fatal_error(char const*, bool) (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x3d10ab7) #8 0x7f12b501aa4c (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x481aa4c) #9 0x7f12b4feecb3 llvm::SelectionDAG::LegalizeTypes() (/usr/lib/llvm/17/bin/../lib64/libLLVM-17+libcxx.so+0x47eecb3) #10 0x7f12b512f2a1 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/usr
[llvm-bugs] [Bug 81013] Unable to compile LLVM with GCC 8.1
Issue
81013
Summary
Unable to compile LLVM with GCC 8.1
Labels
new issue
Assignees
Reporter
jabraham17
I am currently unable to compile LLVM using GCC 8.1.0. The failure comes from `llvm/lib/Support/APFloat.cpp`, where some versions of GCC do not consider an enum a valid constant _expression_. This only seems to be a problem with GCC 8.1 and 8.2, but these are both supported compilers according to .
Below is the build failure with LLVM 17, although I see looking at `main` that the same code exists and will have the same problem.
```
/llvm-src/lib/Support/APFloat.cpp:127:61: error: 'const llvm::fltSemantics{15, -14, 11, 16, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semIEEEhalf = {15, -14, 11, 16};
^
/llvm-src/lib/Support/APFloat.cpp:128:60: error: 'const llvm::fltSemantics{127, -126, 8, 16, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semBFloat = {127, -126, 8, 16};
^
/llvm-src/lib/Support/APFloat.cpp:129:65: error: 'const llvm::fltSemantics{127, -126, 24, 32, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semIEEEsingle = {127, -126, 24, 32};
^
/llvm-src/lib/Support/APFloat.cpp:130:67: error: 'const llvm::fltSemantics{1023, -1022, 53, 64, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semIEEEdouble = {1023, -1022, 53, 64};
^
/llvm-src/lib/Support/APFloat.cpp:131:69: error: 'const llvm::fltSemantics{16383, -16382, 113, 128, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semIEEEquad = {16383, -16382, 113, 128};
^
/llvm-src/lib/Support/APFloat.cpp:132:61: error: 'const llvm::fltSemantics{15, -14, 3, 8, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semFloat8E5M2 = {15, -14, 3, 8};
^
/llvm-src/lib/Support/APFloat.cpp:141:64: error: 'const llvm::fltSemantics{127, -126, 11, 19, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semFloatTF32 = {127, -126, 11, 19};
^
/llvm-src/lib/Support/APFloat.cpp:142:76: error: 'const llvm::fltSemantics{16383, -16382, 64, 80, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semX87DoubleExtended = {16383, -16382, 64, 80};
^
/llvm-src/lib/Support/APFloat.cpp:143:53: error: 'const llvm::fltSemantics{0, 0, 0, 0, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semBogus = {0, 0, 0, 0};
^
/llvm-src/lib/Support/APFloat.cpp:154:66: error: 'const llvm::fltSemantics{-1, 0, 0, 128, IEEE754, IEEE}' is not a constant _expression_
static constexpr fltSemantics semPPCDoubleDouble = {-1, 0, 0, 128};
^
/llvm-src/lib/Support/APFloat.cpp:181:71: error: 'const llvm::fltSemantics{1023, -969, 106, 128, IEEE754, IEEE}' is not a constant _expression_
53 + 53, 128};
^
[ 25%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Chrono.cpp.o
[ 25%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/COM.cpp.o
[ 25%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/CodeGenCoverage.cpp.o
/llvm-src/lib/Support/APFloat.cpp: In instantiation of 'void llvm::detail::IEEEFloat::initFromIEEEAPInt(const llvm::APInt&) [with const llvm::fltSemantics& S = llvm::semIEEEquad]':
/llvm-src/lib/Support/APFloat.cpp:3818:37: required from here
/llvm-src/lib/Support/APFloat.cpp:3788:10: error: in argument to unary !
(!significand_mask ||
^
/llvm-src/lib/Support/APFloat.cpp: In instantiation of 'void llvm::detail::IEEEFloat::initFromIEEEAPInt(const llvm::APInt&) [with const llvm::fltSemantics& S = llvm::semIEEEdouble]':
/llvm-src/lib/Support/APFloat.cpp:3822:39: required from here
/llvm-src/lib/Support/APFloat.cpp:3788:10: error: in argument to unary !
/llvm-src/lib/Support/APFloat.cpp: In instantiation of 'void llvm::detail::IEEEFloat::initFromIEEEAPInt(const llvm::APInt&) [with const llvm::fltSemantics& S = llvm::semIEEEsingle]':
/llvm-src/lib/Support/APFloat.cpp:3826:39: required from here
/llvm-src/lib/Support/APFloat.cpp:3788:10: error: in argument to unary !
/llvm-src/lib/Support/APFloat.cpp: In instantiation of 'void llvm::detail::IEEEFloat::initFromIEEEAPInt(const llvm::APInt&) [with const llvm::fltSemantics& S = llvm::semBFloat]':
/llvm-src/lib/Support/APFloat.cpp:3830:35: required from here
/llvm-src/lib/Support/APFloat.cpp:3788:10: error: in argument to unary !
/llvm-src/lib/Support/APFloat.cpp: In instantiation of 'void llvm::detail::IEEEFloat::initFromIEEEAPInt(const llvm::APInt&) [with const llvm::fltSemantics& S = llvm::semIEEEhalf]':
/llvm-src/lib/Support/APFloat.cpp:3834:37: required from here
/ll
[llvm-bugs] [Bug 81016] attribute `[[noreturn]]` Diagnoses 'should not return' on a void function
Issue
81016
Summary
attribute `[[noreturn]]` Diagnoses 'should not return' on a void function
Labels
clang:diagnostics
Assignees
Reporter
erichkeane
See https://godbolt.org/z/h5nsj8qEK
```
[[noreturn]]
void foo() {
}
```
```
:3:1: warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
3 | }
| ^
```
We should probably suppress this diagnostic when the function is void .
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81019] Explicit template instantiation rejected when the template is found via `using namespace`
Issue
81019
Summary
Explicit template instantiation rejected when the template is found via `using namespace`
Labels
new issue
Assignees
Reporter
abbeyj
The following code is accepted by GCC, ICC, and MSVC but is rejected by clang with the error `error: explicit instantiation of 'N::C' must occur in namespace 'N'`.
```C++
namespace N {
template
class C {
};
}
using namespace N;
template class C;
```
It is my understanding that rejecting this code used to be the correct behavior according to the standard. See https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#275 , specifically "If the name declared in the explicit instantiation is an unqualified name, the explicit instantiation shall appear in the namespace where its template is declared."
However this language was eventually removed by https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html which is going to be part of C++23.
See also #54150
https://godbolt.org/z/KMY7Me9Es
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81025] [Flang] Incorrect use association for generic names.
Issue 81025 Summary [Flang] Incorrect use association for generic names. Labels flang Assignees Reporter DanielCChen The following test cases crashes. The problem is when procedure pointer `PtrInt8` is declared, its `procInterface` `Int8` is not marked as generic nor specific function, so it is typeless. The `-fdebug-dump-symbols` shows `int8 (Function): Use from int8 in m1`. ``` Module scope: m size=0 alignment=1 sourceRange=156 bytes int, PUBLIC (Function): Subprogram result:INTEGER(4) int (INTEGER(4) arg) int8, PUBLIC (Function): Subprogram result:INTEGER(8) int8 (INTEGER(8) arg) Subprogram scope: int size=8 alignment=4 sourceRange=60 bytes arg size=4 offset=4: ObjectEntity dummy type: INTEGER(4) int size=4 offset=0: ObjectEntity funcResult type: INTEGER(4) Subprogram scope: int8 size=16 alignment=8 sourceRange=66 bytes arg size=8 offset=8: ObjectEntity dummy type: INTEGER(8) int8 size=8 offset=0: ObjectEntity funcResult type: INTEGER(8) Module scope: m1 size=0 alignment=1 sourceRange=98 bytes int, PUBLIC (Function): Use from int in m int8, PUBLIC (Function): Generic Name (specific) procs: int,int8 MainProgram scope: ptrassigngen size=8 alignment=8 sourceRange=216 bytes int (Function): Generic Name (specific) procs: int,int8 int8 (Function): Use from int8 in m1 ptrint8, EXTERNAL, POINTER (Function) size=8 offset=0: ProcEntity int8 ``` I would expect both `Int` and `Int8` are generic names that has specific `Int` and `Int8` from module `m`. ``` MODULE M CONTAINS FUNCTION Int(Arg) INTEGER :: Int, Arg Int = Arg END FUNCTION FUNCTION Int8(Arg) INTEGER(8) :: Int8, Arg Int8 = 8_8 END FUNCTION END MODULE MODULE M1 USE M INTERFACE Int8 MODULE PROCEDURE Int MODULE PROCEDURE Int8 END INTERFACE END MODULE PROGRAM PtrAssignGen USE M USE M1 IMPLICIT NONE INTERFACE Int MODULE PROCEDURE Int MODULE PROCEDURE Int8 END INTERFACE PROCEDURE(Int8), POINTER :: PtrInt8 PtrInt8 => Int8 IF ( PtrInt8(100_8) .NE. 8_8 ) ERROR STOP 12 END ``` ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81036] [HLSL][SPIR-V] Add RWBuffer type support
Issue 81036 Summary [HLSL][SPIR-V] Add RWBuffer type support Labels HLSL, backend:SPIR-V Assignees sudonatalie Reporter sudonatalie Resource types are not yet fully supported. In particular, there is not yet sufficient metadata or resources annotations to provide correct data bindings for Vulkan target environments. However, there should be enough information to support simple construction that passes SPIR-V validation with implicit bindings, which would be a good start. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81043] [FMV] mangling of forward-declared multi-versioned callee differs between gcc and clang
Issue
81043
Summary
[FMV] mangling of forward-declared multi-versioned callee differs between gcc and clang
Labels
clang
Assignees
Reporter
jroelofs
https://clang.godbolt.org/z/zeeTxd3va
```
__attribute__((target_version("fp16")))
void foo(void);
__attribute__((target_version("fp16fml")))
void foo(void);
__attribute__((target_version("default")))
void foo(void);
void caller() {
foo();
}
```
Note how clang calls it `_Z3foov.ifunc`, and gcc refers to it as `_Z3foov`. IMO gcc's behavior is the desirable one: it lets you forward-declare foo in a header without having to promise that the implementation is multi-versioned. This is useful for libraries that have to provide a stable ABI to be able to adopt FMV in the implementation of those interfaces, without having to write an excessive number of shims.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81046] [FMV] -Wunused-function incorrectly complains about versioned static functions
Issue
81046
Summary
[FMV] -Wunused-function incorrectly complains about versioned static functions
Labels
new issue
Assignees
Reporter
jroelofs
https://clang.godbolt.org/z/7zdKf8M9r
```
__attribute__((target_version("fp16")))
static int foo(void) { return 1; }
__attribute__((target_version("fp16fml")))
static int foo(void) { return 2; }
__attribute__((target_version("default")))
static int foo(void) { return 0; }
int caller() {
return foo();
}
```
`-Wunused-function -Werror`
```
:2:12: error: unused function 'foo' [-Werror,-Wunused-function]
2 | static int foo(void) { return 1; }
|^~~
:5:12: error: unused function 'foo' [-Werror,-Wunused-function]
5 | static int foo(void) { return 2; }
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81047] Overload resolution should promote 16-bit types
Issue
81047
Summary
Overload resolution should promote 16-bit types
Labels
HLSL
Assignees
llvm-beanz
Reporter
llvm-beanz
In working on #71098, I've discovered a few cases where C++ overload resolution rules don't quite match HLSL. HLSL allows "promotion" casting 16-bit types to larger types, and will select the first larger type that fits. In the following examples both should resolve successfully to the 32-bit overloads:
```c++
void Fn3(double2 D);
void Fn3(float2 F);
void Call3(half2 H) {
Fn3(H);
}
void Fn4(int64_t2 L);
void Fn4(int2 I);
void Call4(int16_t H) {
Fn4(H);
}
```
### Acceptance Criteria
A test case demonstrating the above overload resolution.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81049] [HLSL] `half` should alias `float` when 16-bit types are not enabled
Issue
81049
Summary
[HLSL] `half` should alias `float` when 16-bit types are not enabled
Labels
HLSL
Assignees
llvm-beanz
Reporter
llvm-beanz
In HLSL `decltype(half) == decltype(float)` when 16-bit types are not enabled. Today that is not the case. When 16-bit types are disabled today `half` is a distinct 32-bit type. This causes challenges in overload resolution. With 16-bit types disabled the following case should have an exact match:
```c++
float fn(float f);
half call(half x)
{
return fn(x);
}
```
### Acceptance Criteria
A test case demonstrating correct overload resolution for the case above.
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81070] Cross-compiling with clang-cl to intel on an arm machine doesn't work great (or at all)
Issue
81070
Summary
Cross-compiling with clang-cl to intel on an arm machine doesn't work great (or at all)
Labels
new issue
Assignees
Reporter
nico
I saw https://neugierig.org/software/blog/2024/02/cross-compile.html and was like "this is super easy to do with clang-cl as long as you have a win sysroot!". Then I tried it on my Apple Silicon laptop:
```
% cat main.c
int main() {}
```
```
% out/gn/bin/clang-cl main.c /winsysroot ~/src/chrome/src/third_party/depot_tools/win_toolchain/vs_files/27370823e7
clang-cl: error: unable to execute command: Executable "link.exe" doesn't exist!
clang-cl: error: linker command failed with exit code 1 (use -v to see invocation)
```
Ah right, I have to use lld, of course:
```
% out/gn/bin/clang-cl main.c /winsysroot ~/src/chrome/src/third_party/depot_tools/win_toolchain/vs_files/27370823e7 -fuse-ld=lld
% file main.exe
main.exe: PE32+ executable (console) Aarch64, for MS Windows
```
Hm. I suppose that makes sense? But let's make an intel binary. Just `-m32` picks 32-bit arm which I suppose maybe makes sense, so let's pass an explicit triple:
```
% out/gn/bin/clang-cl main.c /winsysroot ~/src/chrome/src/third_party/depot_tools/win_toolchain/vs_files/27370823e7 -fuse-ld=lld --target=x86_64-pc-windows
clang (LLVM option parsing): Unknown command line argument '-x86-asm-syntax=intel'. Try: 'clang (LLVM option parsing) --help'
clang (LLVM option parsing): Did you mean '--asan-stack=intel'?
```
Whaat? Why is that command line arg unknown? That should work?
I suppose this bug report is only about this very last thing. (But maybe we should default to lld too, at least on non-Win hosts, since link.exe can't possibly work there?)
@zmodem
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81084] Merge 4520b478d2512b0f39764e0464dcb4cb961845b5 into 18.x
Issue 81084 Summary Merge 4520b478d2512b0f39764e0464dcb4cb961845b5 into 18.x Labels new issue Assignees Reporter brad0 MIPS/libunwind: Use -mfp64 if compiler is FPXX (#68521) Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is that, FP64 and FP32 have different way to save/restore FPRs. If libunwind is built as FPXX, we have no idea which one should we use. It's not due to the code bug, but rather the nature of FPXX. FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0 (FP32). So that FPXX binaries can link with both FP64 and FP32 ones, aka. FPXX + FP32 -> FP32 FPXX + FP64 -> FP64 While for libunwind, we should save/restore all of FPRs. If we use FPXX, we can only save/restore a common subset of FPRs, instead of superset. If libunwind is built as FP64, it will interoperatable with FPXX/FP64 APPs, and if it is built as FP32, it will interoperatable with FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are FP32. So if the compiler is FPXX, which is the default value of most toolchain, let's switch it to FP64. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81088] Clang fails when building LLVM for RISCV
Issue 81088 Summary Clang fails when building LLVM for RISCV Labels clang Assignees Reporter kongy `fatal error: error in backend: Do not know how to split the result of this operator!` Reduced reproducer attached. [reduce.zip](https://github.com/llvm/llvm-project/files/14204289/reduce.zip) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81089] Clang rejects valid code for incorrectly choosing protected destructor in list initilization
Issue
81089
Summary
Clang rejects valid code for incorrectly choosing protected destructor in list initilization
Labels
clang
Assignees
Reporter
wangbo15
The following code should be valid accroding to C++ syntax, since the protected destructor of the `Base` class can be implicitly called through the calling of `Derived` class's dtor, which is public:
```c++
struct Base {
protected:
~Base() = default;
};
struct Derived : Base{
};
int main(){
Derived d{};
}
```
However we find it does not compile in `clang 17.0.1` and `clang-trunk`. It comes out that the compiler complains about the usage of protected base destructor. When we replace the statement `Derived d{};` with `Derived d;` in the function `main`, the code compiles well.
```
:10:15: error: temporary of type 'Base' has protected destructor
10 | Derived d{};
| ^
:3:5: note: declared protected here
3 | ~Base() = default;
| ^
1 error generated.
```
[https://godbolt.org/z/3nGbj15M3](https://godbolt.org/z/3nGbj15M3)
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81090] Intrinsics - Do not know how to widen the result of this operator
Issue 81090 Summary Intrinsics - Do not know how to widen the result of this operator Labels new issue Assignees Reporter AldrinMathew This happens whenever I use llvm intrinsics with clang-17, regardless of the intrinsic ### Error Output fatal error: error in backend: Do not know how to widen the result of this operator! Stack dump: - Program arguments: `/mnt/Main/LIBS/llvm-release/bin/clang-17 -c --target=x86_64-unknown-linux-gnu ./test/.qatcache/llvm/file-main.ll -o /mnt/Main/DEV/qatlang/qat/test/.qatcache/object/file-main.o` - Code generation - Running pass 'Function Pass Manager' on module './test/.qatcache/llvm/file-main.ll'. - Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' ``` #0 0x55625b197970 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6acd970) #1 0x55625b195844 llvm::sys::CleanupOnSignal(unsigned long) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6acb844) #2 0x55625b0d4087 llvm::CrashRecoveryContext::HandleExit(int) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6a0a087) #3 0x55625b18d3a2 llvm::sys::Process::Exit(int, bool) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6ac33a2) #4 0x5562588dd527 (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x4213527) #5 0x55625b0de260 llvm::report_fatal_error(llvm::Twine const&, bool) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6a14260) #6 0x55625b0de3fe (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6a143fe) #7 0x55625c522a2d llvm::DAGTypeLegalizer::WidenVectorResult(llvm::SDNode*, unsigned int) LegalizeVectorTypes.cpp:0:0 #8 0x55625c4b9f4d llvm::DAGTypeLegalizer::run() LegalizeTypes.cpp:0:0 #9 0x55625c4ba8ce llvm::SelectionDAG::LegalizeTypes() (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7df08ce) #10 0x55625c483765 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7db9765) #11 0x55625c4865cc llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7dbc5cc) #12 0x55625c48896e llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.0) SelectionDAGISel.cpp:0:0 #13 0x55625a007f85 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) X86ISelDAGToDAG.cpp:0:0 #14 0x55625a5b46b4 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0 #15 0x55625aaef52a llvm::FPPassManager::runOnFunction(llvm::Function&) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x642552a) #16 0x55625aaef6b4 llvm::FPPassManager::runOnModule(llvm::Module&) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x64256b4) #17 0x55625aaf00b4 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x64260b4) #18 0x55625ba27720 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr, std::unique_ptr>) (/mnt /Main/LIBS/llvm-release/bin/clang-17+0x735d720) #19 0x55625bf61423 clang::CodeGenAction::ExecuteAction() (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7897423) #20 0x55625be6c179 clang::FrontendAction::Execute() (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x77a2179) #21 0x55625bdf0c11 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7726c11) #22 0x55625bf3fee3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7875ee3) #23 0x5562588df4bb cc1_main(llvm::ArrayRef, char const*, void*) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x42154bb) #24 0x5562588d7a6d ExecuteCC1Tool(llvm::SmallVectorImpl&, llvm::ToolContext const&) driver.cpp:0:0 #25 0x55625bc2e3dd void llvm::function_ref::callback_fn>, std::__cxx11::basic_string, std::allocator>*, bool*) const::'lambda'()>(long) Job.cpp:0:0 #26 0x55625b0d3f77 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref) (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x6a09f77) #27 0x55625bc2e777 clang::driver::CC1Command::Execute(llvm::ArrayRef>, std::__cxx11::basic_string, std::allocator>*, bool*) co nst (.part.0) Job.cpp:0:0 #28 0x55625bbf3611 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/mnt/Main/LIBS/llvm-release/bin/clang-17+0x7529611) #29 0x55625bbf40cd clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl>&, bool) const (/mnt/Main/LIBS/llv m-release/bin/clang-17+0x752a0cd) #30 0x55625bc0537c clang::driver::Driver::ExecuteCompilat
[llvm-bugs] [Bug 81091] Cannot find location for unit tests of __wrap_iter
Issue 81091 Summary Cannot find location for unit tests of __wrap_iter Labels Assignees Reporter hawkinsw Hello! I was looking through the iterator unit tests last night and could not track down any unit tests for the `__wrap_iter` iterator type. If there are none, I would be more than happy to write a first batch. If, however, I just simply was too ignorant to find them, please let me know! Will ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81097] [Flang] Compilation error of a DATA-stmt-like initialization for a component of a derived type
Issue 81097 Summary [Flang] Compilation error of a DATA-stmt-like initialization for a component of a derived type Labels flang:frontend, crash Assignees Reporter yus3710-fj This is an issue from Fujitsu testsuite. Flang-new terminates abnormally when compiling a DATA-stmt-like initialization for a component of a derived type. This is not Fortran standard, but the following statement exists in [Extensions.md](https://github.com/llvm/llvm-project/blob/main/flang/docs/Extensions.md). > * Initialization in type declaration statements using `/values/` I'm not sure this includes the case of a component of a derived type, but flang-new should emit a correct error message if this shouldn't be accepted. The following are the test program and the compilation results of Flang-new and gfortran. ```fortran ! test.f90 integer i/1/ ! flang-new, gfortran, ifort and Fujitsu compiler accept this type tag31 integer i/1/ ! only Fujitsu compiler accepts this end type end ``` ```console $ flang-new -v test.f90 flang-new version 18.0.0git (https://github.com/llvm/llvm-project.git 61ff9f8db8d18002767ea27f83a4bfb8ed47f255) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: /path/to/install/bin Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12 Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/path/to/install/bin/flang-new" -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-a5f676.o -x f95-cpp-input test.f90 fatal internal error: CHECK(exprAnalyzer_.context().AnyFatalError()) failed at /path/to/llvm-project/flang/lib/Semantics/data-to-inits.cpp(375) PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /path/to/install/bin/flang-new -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-a5f676.o -x f95-cpp-input test.f90 #0 0xa5276dc0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/path/to/install/lib/libLLVMSupport.so.19git+0x1a6dc0) #1 0xa5274cf0 llvm::sys::RunSignalHandlers() (/path/to/install/lib/libLLVMSupport.so.19git+0x1a4cf0) #2 0xa5274e74 SignalHandler(int) Signals.cpp:0:0 #3 0xa7c107a0 (linux-vdso.so.1+0x7a0) #4 0xa4cc6274 raise (/lib64/libc.so.6+0x36274) #5 0xa4cb0a2c abort (/lib64/libc.so.6+0x20a2c) #6 0x9c1c241c (/path/to/install/lib/libFortranCommon.so.19git+0x241c) #7 0x9ff3934c Fortran::semantics::DataInitializationCompiler>::InitElement(Fortran::evaluate::OffsetSymbol const&, Fortran::evaluate::Expr const&) (/path/to/install/lib/libFortranSemantics.so.19git+0x1f6934c) #8 0x9ff39c5c Fortran::semantics::DataInitializationCompiler>::InitDesignator(Fortran::evaluate::Expr const&) (/path/to/install/lib/libFortranSemantics.so.19git+0x1f69c5c) #9 0x9ff39ebc Fortran::semantics::AccumulateDataInitializations(std::map, std::allocator>>&, Fortran::evaluate::ExpressionAnalyzer&, Fortran::semantics::Symbol const&, std::__cxx11::list, std::allocator>> const&) (/path/to/install/lib/libFortranSemantics.so.19git+0x1f69ebc) #10 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x2125068) #11 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x2126568) #12 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x215ae68) #13 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x215b12c) #14 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x215b278) #15 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x2117c1c) #16 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x2147768) #17 ... (/path/to/install/lib/libFortranSemantics.so.19git+0x21478ec) #18 0xa011837c void Fortran::parser::ForEachInTuple<0ul, void Fortran::parser::Walk, std::optional>, Fortran::parser::SpecificationPart, Fortran::parser::ExecutionPart, std::optional, Fortran::parser::Statement>(std::tuple>, Fortran::parser::SpecificationPart, Fortran::parser::ExecutionPart, std::optional, Fortran::parser::Statement> const&, Fortran::semantics::SemanticsVisitor&)::'lambda'(Fortran::semantics::SemanticsVisitor const&), std::tuple>, Fortran::parser::SpecificationPart, Fortran::parser::ExecutionPart, std::optional, Fortran::parser::Statement>>(std::tuple>, Fortran::parser::SpecificationP
[llvm-bugs] [Bug 81099] [Flang][OpenMP] Compilation error of `atomic update` with `MAX` for variables of different types
Issue
81099
Summary
[Flang][OpenMP] Compilation error of `atomic update` with `MAX` for variables of different types
Labels
openmp,
flang
Assignees
Reporter
yus3710-fj
This is an issue from Fujitsu testsuite.
Flang-new terminates abnormally when compiling in `atomic update` with `MAX` for variables of different types.
Gfortran emits error messages even if OpenMP is disabled.
The following are the test program and the compilation results of Flang-new and gfortran.
```fortran
! test.f90
program main
call isub1()
end program main
subroutine isub1()
integer*1 i1x, i1y
integer*2 i2x, i2y
integer*4 i4x, i4y, calc(6),res/4/
integer*8 i8x, i8y
real*4 r4x, r4y
real*8 r8x, r8y
data i1x,i2x,i4x,i8x,r4x,r8x/6*-2/
data i1y,i2y,i4y,i8y,r4y,r8y/6*4/
!$omp atomic update
i4x = max(i4x , i1y)
!$omp end atomic
calc(1) = i4x
i4x = -2
!$omp atomic update
i4x = max(i4x , i2y)
!$omp end atomic
calc(2) = i4x
i4x = -2
!$omp atomic update
i4x = max(i4x , i4y)
!$omp end atomic
calc(3) = i4x
i4x = -2
!$omp atomic update
i4x = max(i4x , i8y)
!$omp end atomic
calc(4) = i4x
i4x = -2
!$omp atomic update
i4x = max(i4x , r4y)
!$omp end atomic
calc(5) = i4x
i4x = -2
!$omp atomic update
i4x = max(i4x , r8y)
!$omp end atomic
calc(6) = i4x
end subroutine
```
```console
$ flang-new -v test.f90 -fopenmp
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 61ff9f8db8d18002767ea27f83a4bfb8ed47f255)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /path/to/install/bin
Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/path/to/install/bin/flang-new" -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fopenmp -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-3ff5d4.o -x f95-cpp-input test.f90
error: loc("/path/to/test.f90":30:3): no atomic update operation with region argument as operand found inside atomic.update region
error: loc("/path/to/test.f90":30:3): LLVM Translation failed for operation: omp.atomic.update
error: failed to create the LLVM module
```
```console
$ gfortran -v test.f90 -fopenmp
Driving: gfortran -v test.f90 -fopenmp -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/8/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --disable-libmpx --enable-gnu-indirect-function --build=aarch64-redhat-linux
Thread model: posix
gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
:
test.f90:33:15:
i4x = max(i4x , i8y)
1
Error: !$OMP ATOMIC intrinsic arguments except one must not reference ‘i4x’ at (1)
test.f90:38:23:
i4x = max(i4x , r4y)
1
Error: ‘a2’ argument of ‘max’ intrinsic at (1) must be INTEGER(4)
test.f90:38:11:
i4x = max(i4x , r4y)
1
Error: !$OMP ATOMIC assignment must have an operator or intrinsic on right hand side at (1)
test.f90:43:23:
i4x = max(i4x , r8y)
1
Error: ‘a2’ argument of ‘max’ intrinsic at (1) must be INTEGER(4)
test.f90:43:11:
i4x = max(i4x , r8y)
1
Error: !$OMP ATOMIC assignment must have an operator or intrinsic on right hand side at (1)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 81100] [Flang][OpenMP] flang-new doesn't report a wrong usage of `atomic capture`
Issue
81100
Summary
[Flang][OpenMP] flang-new doesn't report a wrong usage of `atomic capture`
Labels
openmp,
flang:frontend
Assignees
Reporter
yus3710-fj
This is an issue from Fujitsu testsuite.
Flang-new doesn't emit a correct error message for a wrong usage of `atomic capture`.
The following are the test program and the compilation results of Flang-new and gfortran.
```fortran
! test.f90
integer :: vv,yy,yy1
vv=1
yy=1
yy1=1
!$omp atomic capture
vv=yy
yy=yy+yy
!$omp end atomic
!$omp atomic capture
vv=yy
yy=(yy1+yy)+yy1
!$omp end atomic
end
```
```console
$ flang-new -v test.f90 -fopenmp
flang-new version 19.0.0git (https://github.com/llvm/llvm-project.git 61ff9f8db8d18002767ea27f83a4bfb8ed47f255)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /path/to/install/bin
Found candidate GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Selected GCC installation: /opt/rh/gcc-toolset-12/root/usr/lib/gcc/aarch64-redhat-linux/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/path/to/install/bin/flang-new" -fc1 -triple aarch64-unknown-linux-gnu -emit-obj -fopenmp -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu generic -target-feature +v8a -target-feature +fp-armv8 -target-feature +neon -mframe-pointer=non-leaf -o /tmp/test-af2dc0.o -x f95-cpp-input test.f90
error: loc("/path/to/test.f90":4:1): no atomic update operation with region argument as operand found inside atomic.update region
error: LLVM Translation failed for operation: omp.atomic.capture
error: failed to create the LLVM module
```
```console
$ gfortran -v test.f90 -fopenmp
Driving: gfortran -v test.f90 -fopenmp -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/8/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --disable-libmpx --enable-gnu-indirect-function --build=aarch64-redhat-linux
Thread model: posix
gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
:
test.f90:9:3:
yy=yy+yy
1
Error: expr in !$OMP ATOMIC assignment var = var op expr must be scalar and cannot reference var at (1)
test.f90:14:3:
yy=(yy1+yy)+yy1
1
Error: !$OMP ATOMIC assignment must be var = var op expr or var = expr op var at (1)
```
___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
