[llvm-bugs] [Bug 21543] Support 64 bit long double
https://bugs.llvm.org/show_bug.cgi?id=21543 Fangrui Song changed: What|Removed |Added CC||i...@maskray.me Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- D64067/rC365412 added support for -mlong-double-64 on x86 and PPC. -- 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 41296] Add -ldl when linking libclang.so
https://bugs.llvm.org/show_bug.cgi?id=41296 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- Fixed by rC226609 find_library(DL_LIBRARY_PATH dl) if (DL_LIBRARY_PATH) list(APPEND LIBS dl) endif() A better approach is probably to refactor CIndexer::getClangResourcesPath to use getMainExecutable in LLVMSupport -- 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 42706] New: Assertion `HeaderDefBlock && "no definition in header of carrying loop"' failed in SyncDependenceAnalysis
https://bugs.llvm.org/show_bug.cgi?id=42706 Bug ID: 42706 Summary: Assertion `HeaderDefBlock && "no definition in header of carrying loop"' failed in SyncDependenceAnalysis Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: jay.f...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 22266 --> https://bugs.llvm.org/attachment.cgi?id=22266&action=edit test case With the attached test case I get: $ ~/llvm-debug/bin/opt -S -use-gpu-divergence-analysis -divergence stripped.ll opt: /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/SyncDependenceAnalysis.cpp:312: std::unique_ptr llvm::DivergencePropagator::computeJoinPoints(const llvm::BasicBlock &, SuccessorIterable, const llvm::Loop *, const llvm::BasicBlock *) [SuccessorIterable = llvm::iterator_range >]: Assertion `HeaderDefBlock && "no definition in header of carrying loop"' failed. Stack dump: 0. Program arguments: /home/jayfoad2/llvm-debug/bin/opt -S -use-gpu-divergence-analysis -divergence stripped.ll 1. Running pass 'Function Pass Manager' on module 'stripped.ll'. 2. Running pass 'Legacy Divergence Analysis' on function '@llpc.shader.CS.main' #0 0x05fa0889 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/jayfoad2/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:533:11 #1 0x05fa0a39 PrintStackTraceSignalHandler(void*) /home/jayfoad2/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:594:1 #2 0x05f9f276 llvm::sys::RunSignalHandlers() /home/jayfoad2/git/llvm-project/llvm/lib/Support/Signals.cpp:67:5 #3 0x05fa112b SignalHandler(int) /home/jayfoad2/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:385:1 #4 0x7fca691cc890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890) #5 0x7fca67e92e97 raise /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #6 0x7fca67e94801 abort /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0 #7 0x7fca67e8439a __assert_fail_base /build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0 #8 0x7fca67e84412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412) #9 0x04e3db75 std::unique_ptr, std::default_delete > > llvm::DivergencePropagator::computeJoinPoints > >(llvm::BasicBlock const&, llvm::iterator_range >, llvm::Loop const*, llvm::BasicBlock const*) /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/SyncDependenceAnalysis.cpp:0:7 #10 0x04e3c5e4 llvm::SyncDependenceAnalysis::join_blocks(llvm::Instruction const&) /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/SyncDependenceAnalysis.cpp:381:32 #11 0x04c1abf3 llvm::DivergenceAnalysis::propagateBranchDivergence(llvm::Instruction const&) /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/DivergenceAnalysis.cpp:311:36 #12 0x04c1b106 llvm::DivergenceAnalysis::compute() /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/DivergenceAnalysis.cpp:386:9 #13 0x04c1b54b llvm::GPUDivergenceAnalysis::GPUDivergenceAnalysis(llvm::Function&, llvm::DominatorTree const&, llvm::PostDominatorTree const&, llvm::LoopInfo const&, llvm::TargetTransformInfo const&) /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/DivergenceAnalysis.cpp:446:1 #14 0x04c162c5 std::enable_if::value), std::unique_ptr > >::type llvm::make_unique(llvm::Function&, llvm::DominatorTree&, llvm::PostDominatorTree&, llvm::LoopInfo&, llvm::TargetTransformInfo&) /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/STLExtras.h:1406:10 #15 0x04c14b15 llvm::LegacyDivergenceAnalysis::runOnFunction(llvm::Function&) /home/jayfoad2/git/llvm-project/llvm/lib/Analysis/LegacyDivergenceAnalysis.cpp:331:13 #16 0x055c114c llvm::FPPassManager::runOnFunction(llvm::Function&) /home/jayfoad2/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1648:23 #17 0x055c15a2 llvm::FPPassManager::runOnModule(llvm::Module&) /home/jayfoad2/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1685:16 #18 0x055c1d34 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/jayfoad2/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1750:23 #19 0x055c1848 llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/jayfoad2/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1863:16 #20 0x055c22c1 llvm::legacy::PassManager::run(llvm::Module&) /home/jayfoad2/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1894:3 #21 0x03209671 main /home/jayfoad2/git/llvm-project/llvm/tools/opt/opt.cpp:893:3 #22 0x7fca67e75b97 __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0 #23 0x031c502a _start (/home/jayfoad2/llvm-debug/bin/opt+0x31c502a) Aborted (core dumped) -- You are receiving this mail because: You are on the CC list for the bug.
[llvm-bugs] [Bug 42707] New: Assertion fires in CastExpr::CastConsistency
https://bugs.llvm.org/show_bug.cgi?id=42707
Bug ID: 42707
Summary: Assertion fires in CastExpr::CastConsistency
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: marco.antogn...@arm.com
CC: anastasia.stul...@arm.com, llvm-bugs@lists.llvm.org
Created attachment 22267
--> https://bugs.llvm.org/attachment.cgi?id=22267&action=edit
OpenCL reproducer
Clang crashes when running the attached program using
clang -cc1 -emit-llvm -o - test.cl -cl-std=c++
I believe this crash was introduced with D62584 aka [OpenCL][PR42033] Fix addr
space deduction with template parameters.
The issue is present on trunk and on the 9.x branch.
Here is the output & stacktrace:
test.cl:26:9: error: variable 'f' with type '__generic auto &' has incompatible
initializer of type 'Foo'
auto& f = p.first; // expected-error{{variable 'f' with type '__generic auto
&' has incompatible initializer of type 'Foo'}}
^ ~~~
clang: /work/checkouts/upstreams/llvm/llvm-project/clang/lib/AST/Expr.cpp:1813:
bool clang::CastExpr::CastConsistency() const: Assertion `!Ty.isNull() &&
!SETy.isNull() && Ty.getAddressSpace() != SETy.getAddressSpace()' failed.
Stack dump:
0. Program arguments: clang -cc1 -emit-llvm -o - test.cl -cl-std=c++
1. test.cl:27:21: current parser token ';'
2. test.cl:24:22: parsing function body 'foobar'
3. test.cl:24:22: in compound statement ('{}')
#0 0x7fb64fa8c6b9 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/work/checkouts/upstreams/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:533:11
#1 0x7fb64fa8c869 PrintStackTraceSignalHandler(void*)
/work/checkouts/upstreams/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:594:1
#2 0x7fb64fa8b0d6 llvm::sys::RunSignalHandlers()
/work/checkouts/upstreams/llvm/llvm-project/llvm/lib/Support/Signals.cpp:67:5
#3 0x7fb64fa8cf3b SignalHandler(int)
/work/checkouts/upstreams/llvm/llvm-project/llvm/lib/Support/Unix/Signals.inc:385:1
#4 0x7fb64ed62390 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#5 0x7fb64c0ef428 raise (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
#6 0x7fb64c0f102a abort (/lib/x86_64-linux-gnu/libc.so.6+0x3702a)
#7 0x7fb64c0e7bd7 (/lib/x86_64-linux-gnu/libc.so.6+0x2dbd7)
#8 0x7fb64c0e7c82 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc82)
#9 0x7fb649dd7630 clang::CastExpr::CastConsistency() const
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/AST/Expr.cpp:1814:5
#10 0x7fb649b45597 clang::CastExpr::CastExpr(clang::Stmt::StmtClass,
clang::QualType, clang::ExprValueKind, clang::CastKind, clang::Expr*, unsigned
int)
/work/checkouts/upstreams/llvm/llvm-project/clang/include/clang/AST/Expr.h:3154:5
#11 0x7fb649dee3f2
clang::ImplicitCastExpr::ImplicitCastExpr(clang::QualType, clang::CastKind,
clang::Expr*, unsigned int, clang::ExprValueKind)
/work/checkouts/upstreams/llvm/llvm-project/clang/include/clang/AST/Expr.h:3251:75
#12 0x7fb649dd8175 clang::ImplicitCastExpr::Create(clang::ASTContext
const&, clang::QualType, clang::CastKind, clang::Expr*,
llvm::SmallVector const*, clang::ExprValueKind)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/AST/Expr.cpp:1987:5
#13 0x7fb6478d5bd0 clang::Sema::ImpCastExprToType(clang::Expr*,
clang::QualType, clang::CastKind, clang::ExprValueKind,
llvm::SmallVector const*,
clang::Sema::CheckedConversionKind)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Sema/Sema.cpp:536:10
#14 0x7fb6480b842c
clang::Sema::PerformQualificationConversion(clang::Expr*, clang::QualType,
clang::ExprValueKind, clang::Sema::CheckedConversionKind)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Sema/SemaInit.cpp:7368:10
#15 0x7fb6480ba34b clang::InitializationSequence::Perform(clang::Sema&,
clang::InitializedEntity const&, clang::InitializationKind const&,
llvm::MutableArrayRef, clang::QualType*)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Sema/SemaInit.cpp:7766:19
#16 0x7fb647a690cb clang::Sema::AddInitializerToDecl(clang::Decl*,
clang::Expr*, bool)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Sema/SemaDecl.cpp:11518:33
#17 0x7fb6487178ae
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2364:5
#18 0x7fb648715f9e clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
/work/checkouts/upstreams/llvm/llvm-project/clang/lib/Parse/ParseDecl.cpp:2098:9
#19 0x7fb6487111a2
clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesW
[llvm-bugs] [Bug 42708] New: Vectorization of 8 byte load prevents load merging
https://bugs.llvm.org/show_bug.cgi?id=42708
Bug ID: 42708
Summary: Vectorization of 8 byte load prevents load merging
Product: libraries
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: chf...@gmail.com
CC: llvm-bugs@lists.llvm.org
The following C++ load64le() function implements loading of an little-endian
uint64_t.
using uint64_t = unsigned long;
uint64_t load64le(const unsigned char *bytes) noexcept {
return uint64_t{bytes[0]} | (uint64_t{bytes[1]} << 8) |
(uint64_t{bytes[2]} << 16) | (uint64_t{bytes[3]} << 24) |
(uint64_t{bytes[4]} << 32) | (uint64_t{bytes[5]} << 40) |
(uint64_t{bytes[6]} << 48) | (uint64_t{bytes[7]} << 56);
}
Up to clang 8 this is properly optimized to single mov instruction.
But starting from clang 8 when AVX2 support is enabled (-mavx2),
the shift left in the code is vectorized and we get pretty crazy result:
-O2 -g0 -mavx2
.LCPI0_0:
.quad 8 # 0x8
.quad 16 # 0x10
.quad 24 # 0x18
.quad 32 # 0x20
load64le(unsigned char const*): # @load64le(unsigned
char const*)
# %bb.0:
vpmovzxbq ymm0, dword ptr [rdi + 1] # ymm0 =
mem[0],zero,zero,zero,zero,zero,zero,zero,mem[1],zero,zero,zero,zero,zero,zero,zero,mem[2],zero,zero,zero,zero,zero,zero,zero,mem[3],zero,zero,zero,zero,zero,zero,zero
vpsllvq ymm0, ymm0, ymmword ptr [rip + .LCPI0_0]
movzx eax, byte ptr [rdi]
movzx ecx, byte ptr [rdi + 5]
shl rcx, 40
movzx edx, byte ptr [rdi + 6]
shl rdx, 48
or rdx, rcx
movzx ecx, byte ptr [rdi + 7]
shl rcx, 56
or rcx, rdx
or rcx, rax
vextracti128xmm1, ymm0, 1
vporxmm0, xmm0, xmm1
vpshufd xmm1, xmm0, 78 # xmm1 = xmm0[2,3,0,1]
vporxmm0, xmm0, xmm1
vmovq rax, xmm0
or rax, rcx
vzeroupper
ret
# -- End function
When taking a look on LLVM IR, here is not optimized one:
-O2 -g0 -mavx2 -emit-llvm -Xclang -disable-llvm-optzns
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: nounwind uwtable
define dso_local i64 @_Z8load64lePKh(i8*) #0 {
%2 = alloca i8*, align 8
store i8* %0, i8** %2, align 8, !tbaa !2
%3 = load i8*, i8** %2, align 8, !tbaa !2
%4 = getelementptr inbounds i8, i8* %3, i64 0
%5 = load i8, i8* %4, align 1, !tbaa !6
%6 = zext i8 %5 to i64
%7 = load i8*, i8** %2, align 8, !tbaa !2
%8 = getelementptr inbounds i8, i8* %7, i64 1
%9 = load i8, i8* %8, align 1, !tbaa !6
%10 = zext i8 %9 to i64
%11 = shl i64 %10, 8
%12 = or i64 %6, %11
%13 = load i8*, i8** %2, align 8, !tbaa !2
%14 = getelementptr inbounds i8, i8* %13, i64 2
%15 = load i8, i8* %14, align 1, !tbaa !6
%16 = zext i8 %15 to i64
%17 = shl i64 %16, 16
%18 = or i64 %12, %17
%19 = load i8*, i8** %2, align 8, !tbaa !2
%20 = getelementptr inbounds i8, i8* %19, i64 3
%21 = load i8, i8* %20, align 1, !tbaa !6
%22 = zext i8 %21 to i64
%23 = shl i64 %22, 24
%24 = or i64 %18, %23
%25 = load i8*, i8** %2, align 8, !tbaa !2
%26 = getelementptr inbounds i8, i8* %25, i64 4
%27 = load i8, i8* %26, align 1, !tbaa !6
%28 = zext i8 %27 to i64
%29 = shl i64 %28, 32
%30 = or i64 %24, %29
%31 = load i8*, i8** %2, align 8, !tbaa !2
%32 = getelementptr inbounds i8, i8* %31, i64 5
%33 = load i8, i8* %32, align 1, !tbaa !6
%34 = zext i8 %33 to i64
%35 = shl i64 %34, 40
%36 = or i64 %30, %35
%37 = load i8*, i8** %2, align 8, !tbaa !2
%38 = getelementptr inbounds i8, i8* %37, i64 6
%39 = load i8, i8* %38, align 1, !tbaa !6
%40 = zext i8 %39 to i64
%41 = shl i64 %40, 48
%42 = or i64 %36, %41
%43 = load i8*, i8** %2, align 8, !tbaa !2
%44 = getelementptr inbounds i8, i8* %43, i64 7
%45 = load i8, i8* %44, align 1, !tbaa !6
%46 = zext i8 %45 to i64
%47 = shl i64 %46, 56
%48 = or i64 %42, %47
ret i64 %48
}
And the vectorized one:
-O2 -g0 -mavx2 -emit-llvm
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: norecurse nounwind readonly uwtable
define dso_local i64 @_Z8load64lePKh(i8* nocapture readonly) local_unnamed_addr
#0 {
%2 = load i8, i8* %0, align 1, !tbaa !2
%3 = zext i8 %2 to i64
%4 = getelementptr inbounds i8, i8* %0, i64 1
%5 = bitcast i8* %4 to <4 x i8>*
%6 = load <4 x i8>, <4 x i8>* %5, align 1, !tbaa !2
%7 = zext <4 x i8> %6 to <4 x i64>
%8 = shl nuw nsw <4 x i64> %7,
%9 = getelementptr inbounds i8, i8* %0, i
[llvm-bugs] [Bug 42709] New: Extra stack load/store generated for a volatile {i16, i16} store
https://bugs.llvm.org/show_bug.cgi?id=42709
Bug ID: 42709
Summary: Extra stack load/store generated for a volatile {i16,
i16} store
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: gli...@google.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
For the following program:
$ cat tb.c
typedef struct { short v1, v2;} st_t;
void foo(st_t a) {
volatile st_t b;
b = a;
}
GCC generates a single store to a stack slot:
$ gcc tb.c -O2 -c
$ objdump -d tb.o
...
:
0: 89 7c 24 fc mov %edi,-0x4(%rsp)
4: c3 retq
, whereas Clang uses an extra stack slot to store %rdi for no reason:
$ clang tb.c -O2 -c
$ objdump -d tb.o...
:
0: 89 7c 24 f8 mov %edi,-0x8(%rsp)
4: 8b 44 24 f8 mov -0x8(%rsp),%eax
8: 89 44 24 fc mov %eax,-0x4(%rsp)
c: c3 retq
According to the generated IR Clang chose to use a volatile load for that extra
slot:
; Function Attrs: nounwind uwtable
define dso_local void @foo(i32 %a.coerce) local_unnamed_addr #0 {
entry:
%a.sroa.0 = alloca i32, align 4
%b.sroa.0 = alloca i32, align 4
store i32 %a.coerce, i32* %a.sroa.0, align 4
%b.sroa.0.0.b.0..sroa_cast = bitcast i32* %b.sroa.0 to i8*
call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull
%b.sroa.0.0.b.0..sroa_cast)
%a.sroa.0.0.a.sroa.0.0.a.sroa.0.0.copyload = load volatile i32, i32*
%a.sroa.0, align 4
store volatile i32 %a.sroa.0.0.a.sroa.0.0.a.sroa.0.0.copyload, i32*
%b.sroa.0, align 4
call void @llvm.lifetime.end.p0i8(i64 4, i8* nonnull
%b.sroa.0.0.b.0..sroa_cast)
ret void
}
- maybe that prevented DSE from removing the dead store.
--
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 42710] New: Segmentation Fault when compiling with debug symbols
https://bugs.llvm.org/show_bug.cgi?id=42710 Bug ID: 42710 Summary: Segmentation Fault when compiling with debug symbols Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: cvzakharche...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 22268 --> https://bugs.llvm.org/attachment.cgi?id=22268&action=edit Segfault minimal reproducible example Here is the code and the error, produced by clang compiler both on the latest trunk version and some previous versions (clang-9.0, clang-8.0): https://godbolt.org/z/H523mO I attached the same code here. It produces Segmentation Fault, when compiled on Linux 4.19.59-1-MANJARO with a command: clang++ -std=c++17 -g test_main.cpp It doesn't produce any errors without -g flag. clang version 8.0.0 (tags/RELEASE_800/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin -- 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 42711] New: clang9 -Oz generates incorrect symbols for msvc i386 target
https://bugs.llvm.org/show_bug.cgi?id=42711
Bug ID: 42711
Summary: clang9 -Oz generates incorrect symbols for msvc i386
target
Product: clang
Version: 9.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: wbse...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
Code to Reproduce(from ffmpeg):
#include
#include
#ifndef ff_ctzll
#define ff_ctzll(v) __builtin_ctzll(v)
#endif
#define FFMIN(a,b) ((a) > (b) ? (b) : (a))
#define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
int64_t av_gcd(int64_t a, int64_t b) {
int za, zb, k;
int64_t u, v;
if (a == 0)
return b;
if (b == 0)
return a;
za = ff_ctzll(a);
zb = ff_ctzll(b);
k = FFMIN(za, zb);
u = llabs(a >> za);
v = llabs(b >> zb);
while (u != v) {
if (u > v)
FFSWAP(int64_t, v, u);
v -= u;
v >>= ff_ctzll(v);
}
return (uint64_t)u << k;
}
int main()
{
int v = av_gcd(123, 345);
}
Build Command:
gnu style: clang-9 -Oz -fuse-ld=lld-link-9 --target=i386-pc-windows-msvc
-std=c11 -MD -Wl,-nodefaultlib:libcmt -Wl,-defaultlib:msvcrt clangcl32OzBug.c
vc style: clang-cl -Xclang -Oz --target=i386-pc-windows-msvc -MD
clangcl32OzBug.c
Actual Results:
lld-link-9: error: undefined symbol: ___ashrdi3
>>> referenced by /tmp/clangcl32OzBug-b06f63.o:(_av_gcd)
>>> referenced by /tmp/clangcl32OzBug-b06f63.o:(_av_gcd)
>>> referenced by /tmp/clangcl32OzBug-b06f63.o:(_av_gcd)
lld-link-9: error: undefined symbol: ___ashldi3
>>> referenced by /tmp/clangcl32OzBug-b06f63.o:(_av_gcd)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Expected Results:
no error
Additional Information:
x64 target, clang-8, -Os -O2 no error.
__ashrdi3 exists in libgcc and compiler-rt.
--
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 42713] New: wasm-ld not setting start symbol
https://bugs.llvm.org/show_bug.cgi?id=42713 Bug ID: 42713 Summary: wasm-ld not setting start symbol Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: wasm Assignee: unassignedb...@nondot.org Reporter: i...@iandouglasscott.com CC: llvm-bugs@lists.llvm.org, s...@chromium.org Created attachment 22269 --> https://bugs.llvm.org/attachment.cgi?id=22269&action=edit Script demonstrating the problem Whether or not "--entry" is set explicitly, the resulting wasm object doesn't seem to include a start symbol according to "wasm-objdump" (while it does show one if the start symbol is set another way). The problem should be easy enough to replicate, but I've attached a script demonstrating it anyway. -- 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 42714] New: wasm-ld: error: /tmp/wasm-shared-issue-60c549.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol .L.str; recompile with -fPIC
https://bugs.llvm.org/show_bug.cgi?id=42714 Bug ID: 42714 Summary: wasm-ld: error: /tmp/wasm-shared-issue-60c549.o: relocation R_WASM_MEMORY_ADDR_SLEB cannot be used against symbol .L.str; recompile with -fPIC Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: i...@iandouglasscott.com CC: llvm-bugs@lists.llvm.org Created attachment 22270 --> https://bugs.llvm.org/attachment.cgi?id=22270&action=edit C code that produces this issue The attached C code fails to build with "clang --target=wasm32-unknown-unknown -fPIC -nostdlib -Wl,--shared -Wl,--export-all wasm-shared-issue.c". -- 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 14486 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned NULL
Updates: Labels: Deadline-Approaching Comment #2 on issue 14486 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "Node was deleted but visit returned NULL https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14486#c2 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42603, which changed state. Bug 42603 Summary: clang++ incorrect optimization at -O2 in OpenJDK’s stubRoutines.cpp https://bugs.llvm.org/show_bug.cgi?id=42603 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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 42603] clang++ incorrect optimization at -O2 in OpenJDK’s stubRoutines.cpp
https://bugs.llvm.org/show_bug.cgi?id=42603 Kurt Miller changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from Kurt Miller --- (In reply to Kurt Miller from comment #5) > Please see attached test case. The problem is related to object being > created with -mstack-alignment=16 and then called from another object that > does build with -mstack-alignment=16 so the incoming stack alignment is not > 16 byte aligned. Type-o in above. It should have read "and then called from another object that does *not* build with -mstack-alignment=16". According to this comment: https://bugs.llvm.org/show_bug.cgi?id=40635#c1 it is UB to call a function with higher stack alignment from a function with lower stack alignment which is what is happening here. Since stubRoutines.cpp can assume the stack is 16 byte aligned, the align_up all can be optimized away. In OpenJDK 8u clang builds included -mstackrealign on x86_32 to address this. Restoring this build flag in 11u corrects the issues I was seeing. Changing status to resolved/invalid. -- 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 42715] New: Merge r366699 to the 9.0 branch
https://bugs.llvm.org/show_bug.cgi?id=42715 Bug ID: 42715 Summary: Merge r366699 to the 9.0 branch Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Headers Assignee: unassignedclangb...@nondot.org Reporter: paul_robin...@playstation.sony.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk This is a minor thing to fix the prototype of a few intrinsics. -- 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 42632] Crash with parallel for loop
https://bugs.llvm.org/show_bug.cgi?id=42632 Alexey Bataev 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] Issue 14201 in oss-fuzz: llvm/llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::demangleTemplateInstantiationName
Comment #4 on issue 14201 by tha...@chromium.org: llvm/llvm-microsoft-demangle-fuzzer: Stack-overflow in llvm::ms_demangle::Demangler::demangleTemplateInstantiationName https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14201#c4 The issue here is that demangleTemplateInstantiationName keeps a BackrefContext on the stack, and that is 22 pointers large. So stack_size / 176 is the max number of template instantiation names that work. The report "only" has 57 calls to demangleTemplateInstantiationName on the stack, which is only 10kB large. Maybe oss-fuzz runs with a small stack ulimit? Moving BackrefContext to the heap would probably extend the runway until this happens a lot, but it'd still happen eventually and in practice even 57 calls is very far away from what realistic inputs will have. So I'm not sure anything needs to be done here. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 40483, which changed state. Bug 40483 Summary: [X86] Failure to merge ISD::SUB(x,y) and X86ISD::SUB(x,y) https://bugs.llvm.org/show_bug.cgi?id=40483 What|Removed |Added Status|NEW |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 40483] [X86] Failure to merge ISD::SUB(x, y) and X86ISD::SUB(x, y)
https://bugs.llvm.org/show_bug.cgi?id=40483 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Hans Wennborg --- Merged in r366704. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42675, which changed state. Bug 42675 Summary: Late definition of data-sharing attributes for loop control variables. https://bugs.llvm.org/show_bug.cgi?id=42675 What|Removed |Added Status|NEW |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 42675] Late definition of data-sharing attributes for loop control variables.
https://bugs.llvm.org/show_bug.cgi?id=42675 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged to clang 9 in r366705. -- 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 42716] New: Optimize lerp with two FMAs
https://bugs.llvm.org/show_bug.cgi?id=42716
Bug ID: 42716
Summary: Optimize lerp with two FMAs
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
Tip from: https://devblogs.nvidia.com/lerp-faster-cuda/
float lerp(float a, float b, float c) {
return (1-c)*a +c*b;
}
float lerp2(float a, float b, float c)
{
return a + c * (b - a);
}
float rf2(float a, float b, float c) {
return std::fma(c, b, std::fma(-c, a, a));
}
Clang trunk -Ofast -std=c++17 -mfma
lerp(float, float, float): # @lerp(float, float,
float)
vmovss xmm3, dword ptr [rip + .LCPI0_0] # xmm3 = mem[0],zero,zero,zero
vsubss xmm3, xmm3, xmm2
vmulss xmm1, xmm2, xmm1
vfmadd213ss xmm0, xmm3, xmm1 # xmm0 = (xmm3 * xmm0) + xmm1
ret
lerp2(float, float, float):# @lerp2(float, float,
float)
vsubss xmm1, xmm1, xmm0
vfmadd231ss xmm0, xmm2, xmm1 # xmm0 = (xmm2 * xmm1) + xmm0
ret
rf2(float, float, float): # @rf2(float, float,
float)
vfnmadd213ssxmm0, xmm2, xmm0 # xmm0 = -(xmm2 * xmm0) + xmm0
vfmadd231ss xmm0, xmm2, xmm1 # xmm0 = (xmm2 * xmm1) + xmm0
ret
InstCombine?
A) Missing fold: (1-c)*a +c*b -> a + c * (b - a)
B) Fold a + c * (b - a) to llvm.fma(c, b, llvm.fma(-c, a, a)) if FMA enabled
--
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 42677] Fix sharing of threadprivate variables with TLS support.
https://bugs.llvm.org/show_bug.cgi?id=42677 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r366706. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42677, which changed state. Bug 42677 Summary: Fix sharing of threadprivate variables with TLS support. https://bugs.llvm.org/show_bug.cgi?id=42677 What|Removed |Added Status|NEW |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 42678] wasm-ld fails to generate __wasm_init_tls if .tdata is not the first data segment
https://bugs.llvm.org/show_bug.cgi?id=42678 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r366707. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42678, which changed state. Bug 42678 Summary: wasm-ld fails to generate __wasm_init_tls if .tdata is not the first data segment https://bugs.llvm.org/show_bug.cgi?id=42678 What|Removed |Added Status|NEW |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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42679, which changed state. Bug 42679 Summary: Update to segment type default behavior https://bugs.llvm.org/show_bug.cgi?id=42679 What|Removed |Added Status|NEW |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 42679] Update to segment type default behavior
https://bugs.llvm.org/show_bug.cgi?id=42679 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r366709. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42712, which changed state. Bug 42712 Summary: Please backport r366687 to 9.0 https://bugs.llvm.org/show_bug.cgi?id=42712 What|Removed |Added Status|NEW |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 42715] Merge r366699 to the 9.0 branch
https://bugs.llvm.org/show_bug.cgi?id=42715 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Hans Wennborg --- Merged in r366711 -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42715, which changed state. Bug 42715 Summary: Merge r366699 to the 9.0 branch https://bugs.llvm.org/show_bug.cgi?id=42715 What|Removed |Added Status|NEW |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 42670] Extract variable and class layout code actions are noisy
https://bugs.llvm.org/show_bug.cgi?id=42670 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans Wennborg --- Merged r366443 in r366713 and r366451 in r366714. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42670, which changed state. Bug 42670 Summary: Extract variable and class layout code actions are noisy https://bugs.llvm.org/show_bug.cgi?id=42670 What|Removed |Added Status|NEW |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 42646] [REG 7 -> 9] Completion offers namespace items after Class::
https://bugs.llvm.org/show_bug.cgi?id=42646 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Hans Wennborg --- (In reply to ibiryukov from comment #6) > Also landed r366457 to unbreak tests on windows buildbots. > (passing environment variables on Windows seems to require 'env') Merged both changes to clang 9 in r366717. -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42646, which changed state. Bug 42646 Summary: [REG 7 -> 9] Completion offers namespace items after Class:: https://bugs.llvm.org/show_bug.cgi?id=42646 What|Removed |Added Status|NEW |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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42669, which changed state. Bug 42669 Summary: BackgroundIndex stores data in the wrong place when CDBs overlap https://bugs.llvm.org/show_bug.cgi?id=42669 What|Removed |Added Status|NEW |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 42669] BackgroundIndex stores data in the wrong place when CDBs overlap
https://bugs.llvm.org/show_bug.cgi?id=42669 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Merged both to the 9 branch in r366718. -- 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 42713] wasm-ld not setting start symbol
https://bugs.llvm.org/show_bug.cgi?id=42713 Thomas Lively changed: What|Removed |Added Status|NEW |RESOLVED CC||tliv...@google.com Resolution|--- |WONTFIX --- Comment #1 from Thomas Lively --- I believe this is WAI, since there a few problems with the WebAssembly concept of a start function that make it unusable as a general entry point for many programs. From the docs (https://webassembly.org/docs/modules/#module-start-function): > If the module has a start node defined, the function it refers should be called by the loader after the instance is initialized, including its Memory and Table though Data and Element sections, and before the exported functions are callable. The issue here is that code run by the entry symbol may call out to the host environment which may then try to call code exported by the module, but if this is run as the WebAssembly start function, that exported code would not yet be available. -- 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 42713] wasm-ld not setting start symbol
https://bugs.llvm.org/show_bug.cgi?id=42713 Ian Douglas Scott changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #2 from Ian Douglas Scott --- Interesting. So is it then expected that --entry doesn't really do anything other than (looking at the code in Driver.cpp) verify the symbol exists, set .forceExport to true, and call .setHidden(false)? This isn't really what I'd expect; but I guess this reflects how WASM is unusual in that a wasm file that isn't a "library" can export any number of functions, unlike normal targets with one entry point. In which case I suppose there also should be an additional argument to set the start symbol, though I don't have any immediate need for it. -- 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 42713] wasm-ld not setting start symbol
https://bugs.llvm.org/show_bug.cgi?id=42713 Ian Douglas Scott changed: What|Removed |Added Resolution|FIXED |WONTFIX -- 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 36233] wrong code with opt "-mem2reg -loop-rotate -simplifycfg -instcombine -newgvn" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=36233 Florian Hahn changed: What|Removed |Added CC||florian_h...@apple.com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Florian Hahn --- It looks like this has been fixed as of r366720. Both versions with and without optimizations produce 0 as output for me. -- 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 37676] Intermittent bug in opt with -O3 -newgvn
https://bugs.llvm.org/show_bug.cgi?id=37676 Florian Hahn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||florian_h...@apple.com --- Comment #1 from Florian Hahn --- I cannot reproduce the failure on current trunk (r366720). Please re-open the issue if you are still seeing the miscompile in your unreduced input. Also, I run opt a few times and compared the output, they were all the same. If it is intermittent, how frequently do you see the bad behavior? -- 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 42717] New: Make -thinlto-index-only work well with thin static archives
https://bugs.llvm.org/show_bug.cgi?id=42717
Bug ID: 42717
Summary: Make -thinlto-index-only work well with thin static
archives
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: akhu...@google.com
Reporter: r...@google.com
CC: llvm-bugs@lists.llvm.org, l...@inglorion.net,
peter.sm...@linaro.org
Many build systems (such as LLVM's) are organized as collections of static
archives. Currently, the recommended way to use -thinlto-index-only to
distribute LTO backend actions is to use --start-lib / --end-lib on the command
line:
http://lists.llvm.org/pipermail/llvm-dev/2019-June/133145.html
To ease adoption of thinlto in legacy build systems, LLD should at least handle
thin archives, if not true static archives. There is a discussion of some of
these issues and how to solve them here:
https://reviews.llvm.org/D64461#1586526
It boils down to coming up with a good path for the .thinlto.bc file calculated
here:
http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#1206
With a very Chromium / LLVM perspective on things, I think the ideal index file
name would be something like:
${pathtoobj}/${object_noext}.o # stage1 output
${pathtoobj}/${object_noext}.${binary_noext}.thinlto.bc # index file
${pathtoobj}/${object_noext}.${binary_noext}.imports # import list
${pathtoobj}/${object_noext}.${binary_noext}.o# native output
So, for chromium on Windows, we'd have:
obj/v8/v8_libbase/bits.obj
obj/v8/v8_libbase/bits.d8.thinlto.bc
obj/v8/v8_libbase/bits.d8.o
obj/v8/v8_libbase/bits.chrome_child.thinlto.bc
obj/v8/v8_libbase/bits.chrome_child.o
... one per thinlto binary
I (think?) today the current behavior is that every link will attempt to write
obj/v8/v8_libbase/bits.thinlto.bc, which won't work if the same object is
compiled into two binaries.
Amy expressed interest in working on this.
--
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 42718] New: clang=8.0 behaves different from clang=6.0 it should template as stated by standard - "As is the case with typename, the template prefix is allowed even if the name is not
https://bugs.llvm.org/show_bug.cgi?id=42718
Bug ID: 42718
Summary: clang=8.0 behaves different from clang=6.0 it should
template as stated by standard - "As is the case with
typename, the template prefix is allowed even if the
name is not dependent"
Product: clang
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: vladimir.venedik...@forkbid.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The code example compiles with all compilers except clang=8
https://godbolt.org/z/VpwYDF
#include
struct A {
template void func( T && t ) {}
};
struct B {
void func( int ) {}
};
struct C {
template void func(T && t, U && u) {
//"As is the case with typename, the template prefix is allowed even
if the name is not dependent"
t.template func(std::forward(u));
}
};
int main () {
C c ;
c.func(A(), 1);
c.func(B(), 1);
}
--
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 32100] [lldb] Member variables not updating using var objects
https://bugs.llvm.org/show_bug.cgi?id=32100 Jonas Devlieghere changed: What|Removed |Added CC||jdevliegh...@apple.com Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Jonas Devlieghere --- lldb-mi is no longer part of the lldb repository. -- 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 42719] New: Unit tests in Analysis/BasicAliasAnalysisTest.cpp failing on linux
https://bugs.llvm.org/show_bug.cgi?id=42719 Bug ID: 42719 Summary: Unit tests in Analysis/BasicAliasAnalysisTest.cpp failing on linux Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: douglas_y...@playstation.sony.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org I recently noticed that the two unit tests in llvm/unittests/Analysis/BasicAliasAnalysisTest.cpp started failing in our internal linux build bot: LLVM-Unit::BasicAATest.AliasInstWithFullObjectOfImpreciseSize LLVM-Unit::BasicAATest.AliasInstWithObjectOfImpreciseSize These tests have also been failing for a while it seems in two of the upstream build bots: http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/10285 http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/24658 For the upstream bot clang-cmake-x86_64-avx2-linux, it started failing in build #10285 (testing r365700-r365711), but I don't think any of those changes actually caused the problem. For the upstream bot clang-cmake-x86_64-sde-avx512-linux, the failure appears in the bot history as far back as it currently goes (currently the oldest build is the build of r366312). Internally, our build bot started hitting the failure somewhere between r365857 and r365866. I highly doubt that any of these changes were actually the cause of the problem, as I was able to go back to when the test was added and reproduce the failure internally at that point. What is even odder is that sometimes the test would fail when run within the LIT test framework, but when run on its own, it would fail! When the failing unit test is run in gdb, the error is a SIGSEGV due to an invalid address. The one time I was able to get a stack trace, here is what it looked like: #0 0x555b16b6 in __gnu_cxx::__normal_iterator >*, std::vector >, std::allocator > > > >::__normal_iterator (this=0x7fffdb10, __i=) at /usr/include/c++/8/bits/stl_iterator.h:784 #1 0x555b17de in std::vector >, std::allocator > >>::begin (this=0x1013) at /usr/include/c++/8/bits/stl_vector.h:699 #2 0x556c74cd in llvm::AAResults::alias (this=0x100b, LocA=..., LocB=...) at /mnt/sources/git/merge/llvm/lib/Analysis/AliasAnalysis.cpp:104 #3 0x556f01ae in llvm::AAResultBase::AAResultsProxy::alias (this=0x7fffdcb0, LocA=..., LocB=...) at /mnt/sources/git/merge/llvm/include/llvm/Analysis/AliasAnalysis.h:896 #4 0x556ec2df in llvm::BasicAAResult::aliasCheck (this=0x5666f918, V1=0x56684ac0, V1Size=..., V1AAInfo=..., V2=0x56686488, V2Size=..., V2AAInfo=..., O1=0x56684ac0, O2=0x56686488) at /mnt/sources/git/merge/llvm/lib/Analysis/BasicAliasAnalysis.cpp:1787 #5 0x556e89da in llvm::BasicAAResult::alias (this=0x5666f918, LocA=..., LocB=...) at /mnt/sources/git/merge/llvm/lib/Analysis/BasicAliasAnalysis.cpp:780 #6 0x555b804b in BasicAATest_AliasInstWithObjectOfImpreciseSize_Test::TestBody (this=0x5666f260) at /mnt/sources/git/merge/llvm/unittests/Analysis/BasicAliasAnalysisTest.cpp:93 #7 0x55e3a8e4 in testing::internal::HandleSehExceptionsInMethodIfSupported ( object=0x5666f260, method=&virtual testing::Test::TestBody(), location=0x56319b3b "the test body") at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2402 #8 0x55e352c2 in testing::internal::HandleExceptionsInMethodIfSupported ( object=0x5666f260, method=&virtual testing::Test::TestBody(), location=0x56319b3b "the test body") at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2455 #9 0x55e1d842 in testing::Test::Run (this=0x5666f260) at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2474 #10 0x55e1e000 in testing::TestInfo::Run (this=0x56657d70) at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2656 #11 0x55e1e5ea in testing::TestCase::Run (this=0x56657f10) at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2774 #12 0x55e244f8 in testing::internal::UnitTestImpl::RunAllTests (this=0x56657120) at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:4649 #13 0x55e3ba52 in testing::internal::HandleSehExceptionsInMethodIfSupported (object=0x56657120, method=(bool (testing::internal::UnitTestImpl::*)(testing::internal::UnitTestImpl * const)) 0x55e24226 , location=0x5631a378 "auxiliary test code (environments or event listeners)") at /mnt/sources/git/merge/llvm/utils/unittest/googletest/src/gtest.cc:2402 #14 0x55e35cc9 in testing::internal::HandleExceptionsInMethodIfSupported (object=0x56657120,
