[llvm-bugs] [Bug 47592] New: SROA introduces inttoptr
https://bugs.llvm.org/show_bug.cgi?id=47592
Bug ID: 47592
Summary: SROA introduces inttoptr
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
This is reduced from real-world code.
https://godbolt.org/z/sxj4oz
struct S {
int* data;
int x, y, z;
};
S gen(S a) {
S b;
b.data = a.data;
return b;
}
void escape(S);
int* entry(S a) {
S b = gen(a);
escape(b);
return b.data;
}
or
struct S {
int* data;
int x, y, z;
};
S gen(S a) {
S b;
b.data = a.data;
return b;
}
int cond();
void sync0();
void sync1();
void escape0(int*);
void escape1(int*);
int* entry(S a) {
S b = gen(a);
if(cond()) {
sync0();
escape0(b.data);
} else {
sync1();
escape1(b.data);
}
return b.data;
}
The story is as follows:
* Originally, there was no inttoptr's
* Then InstCombine`s `combineLoadToOperationType()` came, and changed `gen()`
to operate on integers
As per
http://llvm.1065342.n5.nabble.com/RFC-Missing-canonicalization-in-LLVM-td76650.html#none,
i suppose it's it whole purpose..
* Then, SROA sees accesses with non-identical types to that alloca slice - with
i64 and i32*,
and decides to fall-back to largest integer-sized type, so it creates more
load/stores of i64,
that then need to be inttoptr'd.
* We clearly fail to recover from that - no pass manages to cleanup those
inttoptr's.
I have previously proposed https://reviews.llvm.org/D75505, but indeed,
it has some compile-time impact:
https://llvm-compile-time-tracker.com/compare.php?from=871d03a6751e0f82e210c80a881ef357c5633a26&to=782be5b99377b62e998e4157ddede0fa296664b5&stat=instructions
I think we can agree that this situation isn't great.
inttoptr are (nowadays) treated as pretty opaque, so e.g. SCEV will fail to see
that both the %7 and %9 in second example are actually the same pointer..
I'm open to suggestions as to how we can resolve this.
IMHO, `combineLoadToOperationType()` shouldn't exist, but then the RFC didn't
come with an end-to-end test, so it isn't clear what larger problem it is
fixing.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31098] [LV][MemDeps][SCEV] Unable to prove that a dependence-distance is larger than the trip count
https://bugs.llvm.org/show_bug.cgi?id=31098 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED CC||florian_h...@apple.com Resolution|--- |FIXED --- Comment #9 from Florian Hahn --- Looks like the fix was committed a while ago and the example is vectorized now https://godbolt.org/z/1e8144 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47557] opt crashes with "-simplifycfg -instcombine -early-cse-memssa -loop-unroll -loop-unswitch -loop-reduce -loop-simplifycfg": Assertion `MA->use_empty() && "Trying to remove memor
https://bugs.llvm.org/show_bug.cgi?id=47557 Florian Hahn changed: What|Removed |Added Fixed By Commit(s)||57ae9bb93235 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Florian Hahn --- Should be fixed by https://reviews.llvm.org/rG57ae9bb93235 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46840] [AArch64] vqmovun* return types should be unsigned
https://bugs.llvm.org/show_bug.cgi?id=46840 David Spickett changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47454, which changed state. Bug 47454 Summary: regression with passing f16 as parameters in arm-linux https://bugs.llvm.org/show_bug.cgi?id=47454 What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47454] regression with passing f16 as parameters in arm-linux
https://bugs.llvm.org/show_bug.cgi?id=47454 Lucas Prates changed: What|Removed |Added Fixed By Commit(s)||53d238a961d1 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Lucas Prates --- Fixed by commit 53d238a961d1: >$ clang -o test testarmf16.ll -nostartfiles -nodefaultlibs \ > > -target armv7a-unknown-linux-unknown compiler_rt_armv8.ll c_armv8.ll \ > -fuse-ld=/usr/bin/ld.lld -static -Xclang -target-feature -Xclang -32bit > -Xclang \ > -target-feature -Xclang -8msecext -Xclang -target-feature -Xclang -a76 > -Xclang \ > -target-feature -Xclang +aclass -Xclang -target-feature -Xclang \ > -acquire-release -Xclang -target-feature -Xclang -aes -Xclang > -target-feature \ > -Xclang -avoid-movs-shop -Xclang -target-feature -Xclang -avoid-partial-cpsr > \ > -Xclang -target-feature -Xclang -bf16 -Xclang -target-feature -Xclang -cde \ > -Xclang -target-feature -Xclang -cdecp0 -Xclang -target-feature -Xclang > -cdecp1 \ > -Xclang -target-feature -Xclang -cdecp2 -Xclang -target-feature -Xclang > -cdecp3 \ > -Xclang -target-feature -Xclang -cdecp4 -Xclang -target-feature -Xclang > -cdecp5 \ > -Xclang -target-feature -Xclang -cdecp6 -Xclang -target-feature -Xclang > -cdecp7 \ > -Xclang -target-feature -Xclang -cheap-predicable-cpsr -Xclang > -target-feature \ > -Xclang -crc -Xclang -target-feature -Xclang -crypto -Xclang -target-feature > \ > -Xclang +d32 -Xclang -target-feature -Xclang +db -Xclang -target-feature \ > -Xclang -dfb -Xclang -target-feature -Xclang -disable-postra-scheduler > -Xclang \ > -target-feature -Xclang -dont-widen-vmovs -Xclang -target-feature -Xclang \ > -dotprod -Xclang -target-feature -Xclang +dsp -Xclang -target-feature > -Xclang \ > -execute-only -Xclang -target-feature -Xclang -expand-fp-mlx -Xclang \ > -target-feature -Xclang -exynos -Xclang -target-feature -Xclang -fp16 > -Xclang \ > -target-feature -Xclang -fp16fml -Xclang -target-feature -Xclang +fp64 > -Xclang \ > -target-feature -Xclang -fp-armv8 -Xclang -target-feature -Xclang > -fp-armv8d16 \ > -Xclang -target-feature -Xclang -fp-armv8d16sp -Xclang -target-feature > -Xclang \ > -fp-armv8sp -Xclang -target-feature -Xclang -fpao -Xclang -target-feature \ > -Xclang +fpregs -Xclang -target-feature -Xclang -fpregs16 -Xclang \ > -target-feature -Xclang +fpregs64 -Xclang -target-feature -Xclang -fullfp16 \ > -Xclang -target-feature -Xclang -fuse-aes -Xclang -target-feature -Xclang \ > -fuse-literals -Xclang -target-feature -Xclang +v4t -Xclang -target-feature \ > -Xclang +v5t -Xclang -target-feature -Xclang +v5te -Xclang -target-feature \ > -Xclang +v6 -Xclang -target-feature -Xclang +v6k -Xclang -target-feature \ > -Xclang +v6m -Xclang -target-feature -Xclang +v6t2 -Xclang -target-feature \ > -Xclang +v7 -Xclang -target-feature -Xclang +v7clrex -Xclang -target-feature > \ > -Xclang -v8.1a -Xclang -target-feature -Xclang -v8.1m.main -Xclang \ > -target-feature -Xclang -v8.2a -Xclang -target-feature -Xclang -v8.3a > -Xclang \ > -target-feature -Xclang -v8.4a -Xclang -target-feature -Xclang -v8.5a > -Xclang \ > -target-feature -Xclang -v8.6a -Xclang -target-feature -Xclang -v8 -Xclang \ > -target-feature -Xclang +v8m -Xclang -target-feature -Xclang -v8m.main > -Xclang \ > -target-feature -Xclang -hwdiv -Xclang -target-feature -Xclang -hwdiv-arm \ > -Xclang -target-feature -Xclang -i8mm -Xclang -target-feature -Xclang > -iwmmxt \ > -Xclang -target-feature -Xclang -iwmmxt2 -Xclang -target-feature -Xclang > -lob \ > -Xclang -target-feature -Xclang -long-calls -Xclang -target-feature -Xclang \ > -loop-align -Xclang -target-feature -Xclang -m3 -Xclang -target-feature > -Xclang \ > -mclass -Xclang -target-feature -Xclang -mp -Xclang -target-feature -Xclang \ > -muxed-units -Xclang -target-feature -Xclang -mve -Xclang -target-feature \ > -Xclang -mve.fp -Xclang -target-feature -Xclang -mve1beat -Xclang \ > -target-feature -Xclang -mve2beat -Xclang -target-feature -Xclang -mve4beat \ > -Xclang -target-feature -Xclang -nacl-trap -Xclang -target-feature -Xclang \ > +neon -Xclang -target-feature -Xclang -neon-fpmovs -Xclang -target-feature \ > -Xclang -neonfp -Xclang -target-feature -Xclang -no-branch-predictor -Xclang > \ > -target-feature -Xclang -no-movt -Xclang -target-feature -Xclang \ > -no-neg-immediates -Xclang -target-feature -Xclang -noarm -Xclang \ > -target-feature -Xclang -nonpipelined-vfp -Xclang -target-feature -Xclang \ > +perfmon -Xclang -target-feature -Xclang -prefer-ishst -Xclang > -target-feature \ > -Xclang -prefer-vmovsr -Xclang -target-feature -Xclang -prof-unpr -Xclang \ > -target-feature -Xclang -r4 -Xclang -target-feature -Xclang -ra
[llvm-bugs] [Bug 47593] New: Failure to optimize bitwise not pattern
https://bugs.llvm.org/show_bug.cgi?id=47593
Bug ID: 47593
Summary: Failure to optimize bitwise not pattern
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f1(int a, int b)
{
return ~(a | b) | (~a & b);
}
This can be optimized to `return ~a;`. This optimization is done by GCC, but
not by LLVM.
See also comparison here : https://godbolt.org/z/vqTW4a
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47594] New: Failure to optimize and+not pattern
https://bugs.llvm.org/show_bug.cgi?id=47594
Bug ID: 47594
Summary: Failure to optimize and+not pattern
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: gabrav...@gmail.com
CC: llvm-bugs@lists.llvm.org
int f(int a, int b)
{
return (a ^ b) | ~(a | b);
}
This can be optimized to `return ~(a & b);`. This optimization is done by GCC,
but not by LLVM.
See also comparison here : https://godbolt.org/z/xjWEbh
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47594] Failure to optimize and+not pattern
https://bugs.llvm.org/show_bug.cgi?id=47594 Sanjay Patel changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||spatel+l...@rotateright.com --- Comment #1 from Sanjay Patel --- That's a duplicate if I'm seeing it correctly... *** This bug has been marked as a duplicate of bug 45984 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23844 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->isGLValue() || E->getType()->isFunctionType() || E->getType()->isVoidType() |
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 23844 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: E->isGLValue() || E->getType()->isFunctionType() || E->getType()->isVoidType() | https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23844#c1 ClusterFuzz testcase 4538602301423616 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009200609:202009210613 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24661 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->getType()->isIntegralOrEnumerationType() && "Invalid evaluation result."
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 24661 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: E->getType()->isIntegralOrEnumerationType() && "Invalid evaluation result." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24661#c1 ClusterFuzz testcase 5089153411448832 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009200609:202009210613 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45861] Incorrect flang permission after install
https://bugs.llvm.org/show_bug.cgi?id=45861 Ye Luo changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||d89c5ae8577264f5dd660906f12 ||577c5fdadf49e Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |tianshilei1...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 25234 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->isRValue() && E->getType()->isRealFloatingType()
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 25234 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: E->isRValue() && E->getType()->isRealFloatingType() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25234#c1 ClusterFuzz testcase 5158338453831680 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=202009200609:202009210613 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47595] New: target memory manager attempts to access device after device de-initialization
https://bugs.llvm.org/show_bug.cgi?id=47595 Bug ID: 47595 Summary: target memory manager attempts to access device after device de-initialization Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: xw111lu...@gmail.com CC: llvm-bugs@lists.llvm.org Since 0289696751e9a959b2413ca26624fc6c91be1eea LIBOMPTARGET_DEBUG=1 prints out Libomptarget --> Done unregistering library! Target CUDA RTL --> Error returned from cuCtxSetCurrent This issue so far doesn't block users but this issue needs to be resolved. Use this bug report to track the status. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47597] New: False positive coming when -isystem is used
https://bugs.llvm.org/show_bug.cgi?id=47597
Bug ID: 47597
Summary: False positive coming when -isystem is used
Product: clang
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: cassio.n...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Consider:
// file: leak.cpp
#include // Google benchmark library
void foo(benchmark::State& state);
int main() {
benchmark::RegisterBenchmark("foo", foo);
}
$ scan-build clang++ -isystem -c leak.cpp
scan-build: Using '/usr/bin/clang-8' for static analysis
In file included from leak.cpp:1:
path-to-benchmark/benchmark/benchmark.h:974:3: warning: Potential memory leak
return internal::RegisterBenchmarkInternal(
^~~
Replacing -isystem with -I silences the warning. If anything, I'd expect
-isystem to issue less warnings than -I and not the other way round. I've
managed to pinpoint the issue (imitating benchmark) in this SSCCE:
// file: leak.hpp
#pragma GCC system_header // removing this line silences the warning
void foo(int*);
void bar() {
foo(new int);
}
// file: leak.cpp
#include "leak.hpp"
int main() {
bar();
}
$ scan-build clang++ -c leak.cpp
scan-build: Using '/usr/bin/clang-8' for static analysis
In file included from leak_tmp.cxx:1:
./leak.hpp:7:1: warning: Potential memory leak
}
^
As said above, I'd expect less warnings with the #pragma than without it.
Actually, in this case, I would prefer no warning at all. It is possible, after
all, that foo frees the memory.
FWIW:
1) '-disable-checker unix.Malloc' does not silence the warning.
2) Same behavior with clang-10.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23377 in oss-fuzz: llvm:clang-fuzzer: ASSERT: E->isRValue() && "missing lvalue-to-rvalue conv in bool condition"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #2 on issue 23377 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: E->isRValue() && "missing lvalue-to-rvalue conv in bool condition" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23377#c2 ClusterFuzz testcase 6314130649907200 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009200609:202009210613 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23873 in oss-fuzz: llvm:clang-fuzzer: ASSERT: (E->getOpcode() == BO_Cmp || E->getType()->isIntegralOrEnumerationType()) && "un
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 23873 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: (E->getOpcode() == BO_Cmp || E->getType()->isIntegralOrEnumerationType()) && "un https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23873#c1 ClusterFuzz testcase 6418114752544768 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009200609:202009210613 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47598] New: Build failures when building on Windows 10 w/ MSVC 2019
https://bugs.llvm.org/show_bug.cgi?id=47598
Bug ID: 47598
Summary: Build failures when building on Windows 10 w/ MSVC
2019
Product: new-bugs
Version: 10.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: zel...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
There's a bunch of issues when trying to build LLVM from scratch on Win 10 w/
MSVC 2019 (or 2017 for that matter). These issues are blocking for me.
First there was an issue with llvm::is_trivially_copyable not being compatible
with std::is_trivially_copyable causing build failure
/// SmallVectorTemplateBase - This is where we put
method
/// implementations that are designed to work with non-POD-like T's.
-template ::value>
+template ::value>
class SmallVectorTemplateBase : public SmallVectorTemplateCommon {
protected:
SmallVectorTemplateBase(size_t Size) : SmallVectorTemplateCommon(Size) {}
After fixing by using std:: then there is
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\llvm\include\llvm/ADT/SmallVector.h(222,34):
error C2280: 'clang::OpaqueValueExpr::OpaqueValueExpr(const
clang::OpaqueValueExpr &)': attempting to reference a deleted function
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\clang\include\clang/AST/Expr.h(1146):
message : compiler has generated 'clang::OpaqueValueExpr::OpaqueValueExpr' here
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\clang\include\clang/AST/Expr.h(1146,1):
message : 'clang::OpaqueValueExpr::OpaqueValueExpr(const clang::OpaqueValueExpr
&)': function was implicitly deleted because a base class invokes a deleted or
inaccessible function 'clang::Expr::Expr(const clang::Expr &)'
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\clang\include\clang/AST/Expr.h(113,3):
message : 'clang::Expr::Expr(const clang::Expr &)': function was explicitly
deleted
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\llvm\include\llvm/ADT/SmallVector.h(219):
message : while compiling class template member function 'void
llvm::SmallVectorTemplateBase::push_back(T &&)'
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
with
[
T=clang::OpaqueValueExpr
]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\clang\lib\Sema\SemaExprCXX.cpp(4987):
message : see reference to function template instantiation 'void
llvm::SmallVectorTemplateBase::push_back(T &&)' being compiled
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
with
[
T=clang::OpaqueValueExpr
]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\llvm\include\llvm/ADT/SmallVector.h(316):
message : see reference to class template instantiation
'llvm::SmallVectorTemplateBase' being compiled
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
with
[
T=clang::OpaqueValueExpr
]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\llvm\include\llvm/ADT/SmallVector.h(838):
message : see reference to class template instantiation
'llvm::SmallVectorImpl' being compiled
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
with
[
T=clang::OpaqueValueExpr
]
X:\radgit\rad\jono\scripts\llvm-build\llvm-project\clang\lib\Sema\SemaExprCXX.cpp(4980):
message : see reference to class template instantiation
'llvm::SmallVector' being compiled
[X:\radgit\rad\jono\scripts\llvm-build\llvm-project\build\tools\clang\lib\Sema\obj.clangSema.vcxproj]
How are you guys building 10.0.1 over there? Looks like you guys need some kind
of prereq system config information or something.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47599] New: Building OpenMP on windows does not look for omp libs in correct directory
https://bugs.llvm.org/show_bug.cgi?id=47599 Bug ID: 47599 Summary: Building OpenMP on windows does not look for omp libs in correct directory Product: new-bugs Version: 10.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: zel...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org This issue occurs on 10,11 and trunk (that I've tested). Building on Windows 10 looks for the libomp* stuff in lib/ and bin/, but the build itself outputs to release/lib and release/bin. To fix this locally I have to build twice. Building once then copying libomp.dll.lib, libomp.lib from release/lib to lib/ and libomp.dll from release/bin to bin/ Then building again as linking will now succeed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47600] New: [SystemZ TTI] Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed.
https://bugs.llvm.org/show_bug.cgi?id=47600 Bug ID: 47600 Summary: [SystemZ TTI] Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 23989 --> https://bugs.llvm.org/attachment.cgi?id=23989&action=edit reduced testcase opt -mtriple=s390x-unknown-linux -mcpu=z13 -o out.opt.ll -O3 tc_SLP_toomanybits.ll APInt.h:1632: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. ... #9 0x02aa1e47f574 llvm::SystemZTTIImpl::getCmpSelInstrCost() ... #18 0x02aa1fb9430e llvm::SLPVectorizerPass::runImpl) ... -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47601] New: Non-reserved names in pstl/execution_impl.h
https://bugs.llvm.org/show_bug.cgi?id=47601
Bug ID: 47601
Summary: Non-reserved names in pstl/execution_impl.h
Product: parallel STL
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: New
Assignee: ldio...@apple.com
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org
The members of __internal::__policy_traits aren't using reserved names:
template <>
struct __policy_traits
{
typedef std::false_type allow_parallel;
typedef std::false_type allow_unsequenced;
typedef std::false_type allow_vector;
};
This means the alias templates following it are broken:
template
using __collector_t =
typename __internal::__policy_traits::type>::__collector_type;
This is invalid, because __collector_type doesn't exist, the member is really
called collector_type (although it shouldn't be).
And later in that file:
template
struct __prefer_unsequenced_tag
and
template
struct __prefer_parallel_tag
These use "policy" which is not a reserved name either.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47602] New: __internal::__lazy_and needs to be more lazy
https://bugs.llvm.org/show_bug.cgi?id=47602
Bug ID: 47602
Summary: __internal::__lazy_and needs to be more lazy
Product: parallel STL
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: New
Assignee: ldio...@apple.com
Reporter: zi...@kayari.org
CC: llvm-bugs@lists.llvm.org
In pstl/include/pstl/internal/execution_impl.h these function templates are
defined:
template
std::false_type __lazy_and(_Tp, std::false_type)
{
return std::false_type{};
};
template
inline _Tp
__lazy_and(_Tp __a, std::true_type)
{
return __a;
}
(There are also __lazy_or function template which seem to be completely
unused).
It gets used in code like this:
template
auto
__is_vectorization_preferred(_ExecutionPolicy&& __exec)
-> decltype(__internal::__lazy_and(__exec.__allow_vector(),
typename
__internal::__is_random_access_iterator<_IteratorTypes...>::type()))
{
return __internal::__lazy_and(__exec.__allow_vector(),
typename
__internal::__is_random_access_iterator<_IteratorTypes...>::type());
}
Where __allow_vector is a specialization of a relatively inexpensive class
template, and __is_random_access_iterator is a recursive class template:
template
struct __is_random_access_iterator
{
static constexpr bool value =
__internal::__is_random_access_iterator<_IteratorType>::value &&
__internal::__is_random_access_iterator<_OtherIteratorTypes...>::value;
typedef std::integral_constant type;
};
template
struct __is_random_access_iterator<_IteratorType>
: std::is_same::iterator_category,
std::random_access_iterator_tag>
{
};
Unless I'm mistaken, the only thing that is lazy here is the instantiation of
__allow_vector::value, which is cheap anyway.
In order to choose an overload of __lazy_and the second argument needs to be
complete, which instantiates
__is_random_access_iterator<_IteratorTypes...>::type which requires the
instantiation of __is_random_access_iterator<_IteratorTypes...>::value, which
is VERY UN-LAZY. It requires instantiating __is_random_access_iterator for
every element of the pack, even if the first element is not a random access
iterator.
A better implementation of __is_random_access_iterator would be:
template
struct __is_random_access_iterator;
template
struct __is_random_access_iterator<_IteratorType>
: std::is_same::iterator_category,
std::random_access_iterator_tag>
{
};
template
struct __is_random_access_iterator
: std::conjunction<__is_random_access_iterator<_IteratorType>,
__is_random_access_iterator<_OtherIteratorTypes>...>::type
{
};
Personally I'd get rid of __lazy_and completely, make
__is_random_access_iterator non-variadic, and write the functions using it like
this (assuming bug 47601 gets fixed so the __alow_vector alias template works):
template
typename std::conjunction<__allow_vector<_ExecutionPolicy>,
__is_random_access_iterator<_IteratorTypes>...>::type
__is_vectorization_preferred(_ExecutionPolicy&&)
{
return {};
}
This is actually lazy. It never instantiates any __is_random_access_iterator
specialization if the __allow_vector trait is false, and only instantiates as
many as needed to determine the answer.
(N.B. the __exec parameter is redundant, since the _ExecutionPolicy type has to
be given explicitly anyway, and that already provides all the information
required, but changing that would require changes to every caller).
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47593] Failure to optimize bitwise not pattern
https://bugs.llvm.org/show_bug.cgi?id=47593 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED CC||llvm-...@redking.me.uk Resolution|--- |DUPLICATE --- Comment #2 from Simon Pilgrim --- *** This bug has been marked as a duplicate of bug 45977 *** -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47454] regression with passing f16 as parameters in arm-linux
https://bugs.llvm.org/show_bug.cgi?id=47454 Simon Pilgrim changed: What|Removed |Added Component|new bugs|Common Code Generator Code Status|RESOLVED|REOPENED Product|new-bugs|libraries Resolution|FIXED |--- --- Comment #13 from Simon Pilgrim --- Keep this open until merged into 11.0 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46725] [meta] 11.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=46725 Bug 46725 depends on bug 47454, which changed state. Bug 47454 Summary: regression with passing f16 as parameters in arm-linux https://bugs.llvm.org/show_bug.cgi?id=47454 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47603] New: [x86] Redundant XORs generated withwith BSR from "__builtin_clz".
https://bugs.llvm.org/show_bug.cgi?id=47603
Bug ID: 47603
Summary: [x86] Redundant XORs generated withwith BSR from
"__builtin_clz".
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: tohe_...@gmx.de
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider the following simple C function to be compiled with Clang:
char Func(unsigned DataOffset)
{
return 31 ^ __builtin_clz(DataOffset);
}
Unfortunately it compiles to this assembly:
bsr eax, edi
xor eax, 31
xor al, 31
ret
The relevant LLVM IR is as follows:
declare i32 @llvm.ctlz.i32(i32, i1 immarg) #1
define signext i8 @Func(i32 %0) {
%2 = tail call i32 @llvm.ctlz.i32(i32 %0, i1 true)
%3 = trunc i32 %2 to i8
%4 = xor i8 %3, 31
ret i8 %4
}
Obviously the two XORs should be entirely eliminated in the generated machine
code. This problem only occurs if the return type is a 8 bit integer (char).
For 16 bit, 32 bit and 64 bit integers the xors are elided correctly. Another
variant that leads to the same issue (without an 8 bit integer) is this:
extern char Lookup[32];
int LookupFunc(unsigned DataOffset)
{
return Lookup[31 ^ __builtin_clz(DataOffset)];
}
With results in the following relevant LLVM IR code:
@Lookup = external dso_local local_unnamed_addr global [32 x i8], align 16
declare i32 @llvm.ctlz.i32(i32, i1 immarg) #1
define i32 @LookupFuncj(i32 %0) {
%2 = tail call i32 @llvm.ctlz.i32(i32 %0, i1 true)
%3 = xor i32 %2, 31
%4 = zext i32 %3 to i64
%5 = getelementptr inbounds [32 x i8], [32 x i8]* @Lookup, i64 0, i64 %4
%6 = load i8, i8* %5, align 1
%7 = sext i8 %6 to i32
ret i32 %7
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47604] New: Assertion failed: Index >= End && "Unexpected parser error."
https://bugs.llvm.org/show_bug.cgi?id=47604 Bug ID: 47604 Summary: Assertion failed: Index >= End && "Unexpected parser error." Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Support Libraries Assignee: unassignedb...@nondot.org Reporter: driveha...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 23990 --> https://bugs.llvm.org/attachment.cgi?id=23990&action=edit Response file that contains '-Xclang' argument. The following assertion is firing when running clang-cl under Windows with a response file that includes '-Xclang' arguments. Assertion failed: Index >= End && "Unexpected parser error.", file C:\src\llvm_package_6923b0a7\llvm-project\llvm\lib\Option\OptTable.cpp, line 482 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: clang-cl @test.rsp #0 0x7ff774a4e716 C:\Program Files\LLVM\bin\clang-cl.exe 0x212e716 (C:\Program Files\LLVM\bin\clang-cl.exe+0x212e716) #1 0x7ff774a4e716 #2 0x7ff774a4e716 (C:\Program Files\LLVM\bin\clang-cl.exe+0x212e716) #3 0x7ffa13801891 (C:\WINDOWS\System32\ucrtbase.dll+0x71891) #4 0x7ffa13802861 (C:\WINDOWS\System32\ucrtbase.dll+0x72861) #5 0x7ffa1380427e (C:\WINDOWS\System32\ucrtbase.dll+0x7427e) #6 0x7ffa13804175 C:\Program Files\LLVM\bin\clang-cl.exe 0x1eb1372 C:\Program Files\LLVM\bin\clang-cl.exe 0x347d #7 0x7ffa13804175 C:\Program Files\LLVM\bin\clang-cl.exe 0x4c7cfa0 (C:\WINDOWS\System32\ucrtbase.dll+0x74175) #8 0x7ffa13804175 #9 0x7ffa13804175 (C:\WINDOWS\System32\ucrtbase.dll+0x74175) 0x7FF774A4E716 (0xC338C19A312B 0x00389318E270 0x0016 0x7FF774A4E710) 0x7FFA13801891 (0x0001 0x7FF7 0x 0x00389318E240), raise() + 0x1E1 bytes(s) 0x7FFA13802861 (0x00020003 0x022C0003 0x7FFA1385DE60 0x7FF778F38C24), abort() + 0x31 bytes(s) 0x7FFA1380427E (0x022CCF753490 0x7FF7747D4701 0x022CCF7A6BA0 0x01E2), _get_wpgmptr() + 0x195E bytes(s) 0x7FFA13804175 (0x01E2 0x7FF778F38C24 0x0002 0x00A3), _get_wpgmptr() + 0x1855 bytes(s) 0x7FFA13804501 (0x7FF7775A0F00 0x7FF7775A13A2 0x00389318EDE0 0x7FF7775A0F00), _wassert() + 0x71 bytes(s) 0x7FF7747D1372 (0x006B 0x 0x022CCF72A160 0x022CCF72A150) 0x7FF77292347D (0x 0x 0x 0x) 0x7FF77759CFA0 (0x 0x 0x 0x) 0x7FFA14EA6FD4 (0x 0x 0x 0x), BaseThreadInitThunk() + 0x14 bytes(s) 0x7FFA1587CEC1 (0x 0x 0x 0x), RtlUserThreadStart() + 0x21 bytes(s) I suspect this was caused by a recent refactoring change: https://reviews.llvm.org/D83530 Note: There appears there is a comment referring a FIXME for "@" support, unknown if it's related: https://github.com/llvm/llvm-project/blob/f8a29b17/llvm/lib/Option/OptTable.cpp#L454 This occurred running Clang version 12.0 from the Windows snapshot build provided from here: http://llvm.org/builds/ (built against commit 6923b0a7 - 28 Aug 2020) I've attached a slimmed down response file that produces the assertion, which can be run: `clang-cl @test.rsp` (this points to building sqlite3.c, however it appears the source file present on the filesystem isn't necessary to trigger the assertion). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44395] [MS] Overaligned objects passed by value on i686-windows-msvc are misaligned
https://bugs.llvm.org/show_bug.cgi?id=44395 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Reid Kleckner --- Fixed, landed. Thanks for the report. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23811 in oss-fuzz: llvm:clang-fuzzer: ASSERT: !isAnnotation() && "getIdentifierInfo() on an annotation token!"
Updates: Labels: Deadline-Approaching Comment #1 on issue 23811 by sheriffbot: llvm:clang-fuzzer: ASSERT: !isAnnotation() && "getIdentifierInfo() on an annotation token!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23811#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 23785 in oss-fuzz: llvm:clang-objc-fuzzer: Segv on unknown address in clang::Parser::parseObjCTypeArgsAndProtocolQualifiers
Updates: Labels: Deadline-Approaching Comment #1 on issue 23785 by sheriffbot: llvm:clang-objc-fuzzer: Segv on unknown address in clang::Parser::parseObjCTypeArgsAndProtocolQualifiers https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23785#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 23792 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference READ in BitcodeReader::parseFunctionBody
Updates: Labels: Deadline-Approaching Comment #1 on issue 23792 by sheriffbot: llvm:llvm-isel-fuzzer--aarch64-O2: Null-dereference READ in BitcodeReader::parseFunctionBody https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23792#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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] Issue 23793 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-licm: ASSERT: VSTOffset == 0 || !F->hasName()
Updates: Labels: Deadline-Approaching Comment #1 on issue 23793 by sheriffbot: llvm:llvm-opt-fuzzer--x86_64-licm: ASSERT: VSTOffset == 0 || !F->hasName() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23793#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 44493] Assertion failure when expanding variadic macros for plist output
https://bugs.llvm.org/show_bug.cgi?id=44493 Chris Hamilton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Chris Hamilton --- Resolved by commit 2697d138a65a51 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47606] New: OpenMP compile error for lastprivate array member if also firstprivate
https://bugs.llvm.org/show_bug.cgi?id=47606
Bug ID: 47606
Summary: OpenMP compile error for lastprivate array member if
also firstprivate
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: OpenMP
Assignee: unassignedclangb...@nondot.org
Reporter: michael.p.r...@intel.com
CC: llvm-bugs@lists.llvm.org
If an array member is used in both firstprivate and lastprivate clauses an
error will occur:
:21:56: error: array type 'char [4]' is not assignable
#pragma omp parallel for firstprivate(y) lastprivate(y)
^
But no problem if firstprivate is not used.
#include
int fails;
struct my_struct {
char y[4];
void work();
void init() { for (int i=0;i<4;++i) y[i] = i; }
void check() { if (y[3]!=42) fails++; }
my_struct() {}
};
void my_struct::work() {
init();
#pragma omp parallel for lastprivate(y)
for (int i=0;i<4;++i) {
y[i] = 42;
}
check();
init();
#pragma omp parallel for firstprivate(y) lastprivate(y)
for (int i=0;i<4;++i) {
y[i] = 42;
}
check();
}
int main()
{
my_struct s;
s.work();
if (fails) printf("failed\n");
else printf("passed\n");
return fails;
}
https://godbolt.org/z/6E9Po5
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47598] Build failures when building on Windows 10 w/ MSVC 2019
https://bugs.llvm.org/show_bug.cgi?id=47598 Eli Friedman changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Eli Friedman --- Okay, thanks. Given there is no 10.0.2, and master and 11.0 work fine, I don't think there's anything else we can do here about the failure. For the warnings, not sure if anyone is actively trying to keep Windows warning-free, but patches would be welcome. (Well, except maybe for the issues with ppcg, since that's code imported from an external project.) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
