[llvm-bugs] [Bug 33451] New: Phabricator/llvm.org mails are sent unencrypted
https://bugs.llvm.org/show_bug.cgi?id=33451 Bug ID: 33451 Summary: Phabricator/llvm.org mails are sent unencrypted Product: Phabricator Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org If using gmail web ui, a red unlocked lock icon is shown left to the recepients list, with tooltip "llvm.org did not encrypt this message" While i understand that all the mail content is already publicly available on phabricator, and in maillist archives, it would probably still be better to fix that warning. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33452] New: [LLDB][MIPS] TestNoreturnUnwind.py Fail
https://bugs.llvm.org/show_bug.cgi?id=33452 Bug ID: 33452 Summary: [LLDB][MIPS] TestNoreturnUnwind.py Fail Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: nitesh.j...@imgtec.com CC: llvm-bugs@lists.llvm.org -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33452] [LLDB][MIPS] TestNoreturnUnwind.py Fail
https://bugs.llvm.org/show_bug.cgi?id=33452 Nitesh Jain changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Nitesh Jain --- yes. Marking it as resolved since it depend on code generated by clang. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33453] New: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
https://bugs.llvm.org/show_bug.cgi?id=33453 Bug ID: 33453 Summary: Assertion `isa(Val) && "cast() argument of incompatible type!"' failed Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 18637 --> https://bugs.llvm.org/attachment.cgi?id=18637&action=edit reduced testcase [with X = llvm::FPMathOperator; Y = const llvm::Operator; typename llvm::cast_retty::ret_type = const llvm::FPMathOperator*] ... #12 0x0158f14a cannotBeOrderedLessThanZeroImpl(llvm::Value const*, llvm::TargetLibraryInfo const*, bool, unsigned int) #13 0x0158f5ce llvm::SignBitMustBeZero(llvm::Value const*, llvm::TargetLibraryInfo const*) #14 0x013a9ee3 llvm::Value* SimplifyIntrinsic(llvm::Function*, llvm::Use*, llvm::Use*, llvm::SimplifyQuery const&, unsigned int) #15 0x013a99a5 llvm::Value* SimplifyCall(llvm::Value*, llvm::Use*, llvm::Use*, llvm::SimplifyQuery const&, unsigned int) #16 0x013a8316 llvm::SimplifyCall(llvm::Value*, llvm::Use*, llvm::Use*, llvm::SimplifyQuery const&) #17 0x01e05ecf llvm::InstCombiner::visitCallInst(llvm::CallInst&) ... bin/opt -O3 -mtriple=s390x-unknown-linux -mcpu=z13 -o out.ll ./fpmathop_isa_fail.ll -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25776] llvm missing opportunities to overlap non-interfering local variables
https://bugs.llvm.org/show_bug.cgi?id=25776 Than McIntosh changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||th...@google.com --- Comment #10 from Than McIntosh --- Marking this as resolved now. With Ariel's recent patch (r305193) we now get the better behavior for the first testcast (stack-ifthen.cc), so this bug can be closed out. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33455] New: LLVMOrcAddObjectFile has no implementation
https://bugs.llvm.org/show_bug.cgi?id=33455 Bug ID: 33455 Summary: LLVMOrcAddObjectFile has no implementation Product: new-bugs Version: 4.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: ken.dom...@gmail.com CC: llvm-bugs@lists.llvm.org I'm building a C# wrapper for LLVM-C using SWIG, generating a wrapper for all functions defined in the header files. LLVMOrcAddObjectFile, defined in .../include/llvm-c/OrcBindings.h, is wrapped but I then found out that there is no implementation. I don't know the intent of the change, which was made in a flurry of check-ins on Oct 27, 2015, but the def should be removed or implemented. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33383] Linking static library does not resolve symbols as gold/ld
https://bugs.llvm.org/show_bug.cgi?id=33383 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Rui Ueyama --- Nice! Since the patch was submitted as https://reviews.llvm.org/rL305218, I'll close the bug. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33456] New: wrong code with "opt -early-cse-memssa -instcombine -jump-threading -mem2reg -newgvn" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=33456
Bug ID: 33456
Summary: wrong code with "opt -early-cse-memssa -instcombine
-jump-threading -mem2reg -newgvn" on x86_64-linux-gnu
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 5.0.0 (trunk 305363)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O3 -mllvm -disable-llvm-optzns -c -emit-llvm -o small.bc -w small.c
$
$ opt -early-cse -instcombine -jump-threading -mem2reg -newgvn -o small-opt.bc
small.bc
$ clang small-opt.bc
$ ./a.out
$
$ opt -early-cse-memssa -instcombine -jump-threading -mem2reg -newgvn -o
small-opt.bc small.bc
$ clang small-opt.bc
$ ./a.out
Floating point exception (core dumped)
$
---
int a = 1, b, c, d, e;
int main ()
{
int f;
if (!d)
{
f = a;
if (c < 1 && a)
L:;
b / f && 0;
}
if (e)
goto L;
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33457] New: wrong code with "opt -early-cse-memssa -instcombine -jump-threading -newgvn" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=33457
Bug ID: 33457
Summary: wrong code with "opt -early-cse-memssa -instcombine
-jump-threading -newgvn" on x86_64-linux-gnu
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
$ clang -v
clang version 5.0.0 (trunk 305363)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -O3 -mllvm -disable-llvm-optzns -w -c -emit-llvm -o small.bc small.c
$
$ opt -early-cse -instcombine -jump-threading -newgvn -o small-opt.bc small.bc
$ clang small-opt.bc; ./a.out
0
$
$ opt -early-cse-memssa -instcombine -jump-threading -newgvn -o small-opt.bc
small.bc
$ clang small-opt.bc
$ ./a.out
0
Segmentation fault (core dumped)
$
--
int printf (const char *, ...);
int a = 6, b[6], c = -1, d, e;
int main ()
{
e = 6;
L:
printf ("%d\n", b[d]);
int g = ~(a && e && 0);
e && 1;
if (e)
g = 1;
int h = ~((g & 8693) ^ c);
d = h;
if (h > 1)
goto L;
return 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33458] New: Clang can't use libgcc from a gcc compiled with --disable-shared
https://bugs.llvm.org/show_bug.cgi?id=33458 Bug ID: 33458 Summary: Clang can't use libgcc from a gcc compiled with --disable-shared Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org In a regular gcc installation there is libgcc.a, libgcc_s.so and libgcc_eh.a. In a regular link libgcc.a and libgcc_s.so are used. In a static link libgcc.a and libgcc_eh.a are used. But when gcc is built with --disable-shared, there is no libgcc_eh.a. Everything is in libgcc.a. This means that clang has to know if the gcc installation is static or not. Currently it assumes it is not. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33424] CodeGen crash for Mips64: Assertion in InstrEmitter:EmitSubregNode
https://bugs.llvm.org/show_bug.cgi?id=33424 Simon Dardis changed: What|Removed |Added Assignee|unassignedb...@nondot.org |simon.dar...@imgtec.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Simon Dardis --- r305389. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32713] mips/mipsel i128 sub/add generates wrong code
https://bugs.llvm.org/show_bug.cgi?id=32713 Simon Dardis changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Simon Dardis --- Sorry for the massive delay. r305389. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33459] New: p static_cast(...) has inconsistent output
https://bugs.llvm.org/show_bug.cgi?id=33459 Bug ID: 33459 Summary: p static_cast(...) has inconsistent output Product: lldb Version: 3.9 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: vi...@nethacker.com CC: llvm-bugs@lists.llvm.org (lldb) version lldb version 3.9.0 ( revision ) (lldb) p r_sigma_float (const float) $11 = 0.050007 (correct) (lldb) p (1.0f / (2 * r_sigma_float * r_sigma_float)) * (1<(51199.99f) (int16_t) $1 = 32767 Technically, this is undefined but the output here matches what g++ does so I think it's good. Clang current returns inconsistent results. Ideally, it would be nice for lldb to print (undefined) or be consistent with whatever compiler you are using. I'm hoping to get clang's behavior changed: https://bugs.llvm.org/show_bug.cgi?id=33448 http://eel.is/c++draft/conv.fpint#1 (lldb) p static_cast((1.0f / (2 * r_sigma_float * r_sigma_float)) * (1<___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33460] New: Assertion failed: NewElts && "Out of memory" on a simple program
https://bugs.llvm.org/show_bug.cgi?id=33460 Bug ID: 33460 Summary: Assertion failed: NewElts && "Out of memory" on a simple program Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ramon.axel...@gmail.com CC: llvm-bugs@lists.llvm.org Compiling a simple DNN based on DLib library. Compiling on windows, visual C++ 2015 using LLVM setup (llvm-2014). Got assertion on out of memory that should not have happen. Code compiles on other compilers. Assertion failed: NewElts && "Out of memory", file C:\src\llvm_package_303050\llvm\lib\Support\SmallVector.cpp, line 36 Assertion failed: NewElts && "Out of memory", file C:\src\llvm_package_303050\llvm\lib\Support\SmallVector.cpp, line 36 1> Wrote crash dump file "C:\Users\ramon\AppData\Local\Temp\CL.exe-90d205.dmp" 1> 0x016C4588 (0x0016 0x03C9C718 0x700B6120 0x0003) 1> 0x70064672 (0x03C9C790 0x03C9C718 0x0238C7FF 0x04EEE3D4), abort() + 0x32 bytes(s) 1> 0x70065CAB (0x0024 0x 0x7D223DD8 0x04EEE3E4), _get_wpgmptr() + 0x154B bytes(s) 1> 0x700650E8 (0x0024 0x016D511A 0x011C5D14 0x016D511A), _get_wpgmptr() + 0x988 bytes(s) 1> 0x70065DA6 (0x03C9C790 0x03C9C718 0x0024 0x7D223DB8), _wassert() + 0x16 bytes(s) 1> 0x016D511A (0x7D223DE4 0x011C6EEB 0x0001 0x072503D0) 1> 0x014F95D7 (0x7CD8C798 0x11D7 0x7CD8C798 0x7CD8D96F) 1> 0x01CE14C1 (0x072503D0 0xE889A2BB 0x072503D0 0x7192) 1> 0x01504244 (0xE889A2BB 0x35308238 0xE889A2BB 0x35308238) 1> 0x014F8702 (0x11D6 0x000B6284 0x03C9160A 0x014F8702) 1> 0x01CE0F9A (0x6EE80103 0xE889A2BB 0x35308238 0x6EE83518) 1> 0x014F8702 (0x6D810040 0x7632 0x03DC4AB8 0x0004) 1> 0x01CDEB96 (0x 0x 0x03DC2AA0 0x0D02F9F0) 1> 0x01CD23B4 (0x04EEE564 0x 0x77787878 0x712C7382) 1> 0x77787856 (0x0129E2F8 0x081CD918 0x 0x), LdrUnlockLoaderLock() + 0x8A4 bytes(s) 1> 0x0129DC0B (0x004E0045 0x00420041 0x0045004C 0x003D0044) 1> 0x005F0052 (0x7A81E614 0x8D00505C 0x04004F3C 0x70535C71) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33461] New: clang crashes with "-mllvm -enable-newgvn": Assertion `Res.second && "Stored expression conflict exists in expression table"' failed.
https://bugs.llvm.org/show_bug.cgi?id=33461 Bug ID: 33461 Summary: clang crashes with "-mllvm -enable-newgvn": Assertion `Res.second && "Stored expression conflict exists in expression table"' failed. Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: helloqi...@gmail.com CC: llvm-bugs@lists.llvm.org The following code crashes the current trunk version at "-O2" with "-mllvm -enable-newgvn". Level "-O1" works fine. I have also a case that fails at "-O3" and above. $ clang-trunk --version clang version 5.0.0 (trunk 305375) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -mllvm -enable-newgvn -O2 abc.c abc.c:8:14: warning: incompatible pointer types initializing 'short *' with an expression of type 'short **'; remove & [-Wincompatible-pointer-types] short *g = &e; ^ ~~ clang-5.0: /home/absozero/trunk/llvm/lib/Transforms/Scalar/NewGVN.cpp:3024: void (anonymous namespace)::NewGVN::verifyStoreExpressions() const: Assertion `Res.second && "Stored expression conflict exists in expression table"' failed. #0 0x01d11794 PrintStackTraceSignalHandler(void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1d11794) #1 0x01d11ab6 SignalHandler(int) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1d11ab6) #2 0x7fbf8330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #3 0x7fbfcb845c37 gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #4 0x7fbfcb849028 abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0 #5 0x7fbfcb83ebf6 __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0 #6 0x7fbfcb83eca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2) #7 0x01bfab94 (anonymous namespace)::NewGVN::runGVN() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bfab94) #8 0x01bfe646 (anonymous namespace)::NewGVNLegacyPass::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1bfe646) #9 0x0189653f llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x189653f) #10 0x0272f556 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x272f556) #11 0x01896c95 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1896c95) #12 0x01e9d0eb clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x1e9d0eb) #13 0x025bc937 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x25bc937) #14 0x02a26916 clang::ParseAST(clang::Sema&, bool, bool) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x2a26916) #15 0x02280758 clang::FrontendAction::Execute() (/home/absozero/trunk/root-clang/bin/clang-5.0+0x2280758) #16 0x022313e1 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x22313e1) #17 0x023070aa clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x23070aa) #18 0x00844d44 cc1_main(llvm::ArrayRef, char const*, void*) (/home/absozero/trunk/root-clang/bin/clang-5.0+0x844d44) #19 0x008428cc main (/home/absozero/trunk/root-clang/bin/clang-5.0+0x8428cc) #20 0x7fbfcb830f45 __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0 #21 0x0083fd49 _start (/home/absozero/trunk/root-clang/bin/clang-5.0+0x83fd49) Stack dump: 0. Program arguments: /home/absozero/trunk/root-clang/bin/clang-5.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name abc.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/absozero/trunk/root-clang/lib/clang/5.0.0 -internal-isystem /usr/local/include -internal-isystem /home/absozero/trunk/root-clang/lib/clang/5.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /home/absozero/projects/reduction/crash -ferror-limit 19 -fmessage-length 172 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops
[llvm-bugs] [Bug 33406] clang crashes on valid code at -O1 and above running pass 'Early CSE w/ MemorySSA' (with "-mllvm -enable-earlycse-memssa")
https://bugs.llvm.org/show_bug.cgi?id=33406 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Davide Italiano --- r305409 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33412] opt crashes with "opt -mem2reg -early-cse-memssa": Assertion `isa(Val) && "cast() argument of incompatible type!"' failed
https://bugs.llvm.org/show_bug.cgi?id=33412 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Davide Italiano --- r305409 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33413] opt crashes with "opt -early-cse-memssa": Assertion `Val && "isa<> used on a null pointer"' failed
https://bugs.llvm.org/show_bug.cgi?id=33413 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Davide Italiano --- r305409 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33462] New: segfault when using LTO
https://bugs.llvm.org/show_bug.cgi?id=33462 Bug ID: 33462 Summary: segfault when using LTO Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org lld with LTO is segfaulting when linking our C library. This is a regression as this was working as of r300385. The reproducer is at https://storage.googleapis.com/fuchsia-build/lld/crash.cpio. The stack trace is: ld.lld: ../../lib/IR/Globals.cpp:317: llvm::GlobalVariable::GlobalVariable(llvm::Module &, llvm::Type *, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant *, const llvm::Twine &, llvm::GlobalVariable *, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool): Assertion `!Ty->isFunctionTy() && PointerType::isValidElementType(Ty) && "invalid type for global variable"' failed. #0 0x01f3be19 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:398:11 #1 0x01f3bfc9 PrintStackTraceSignalHandler(void*) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:462:1 #2 0x01f3a633 llvm::sys::RunSignalHandlers() /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Signals.cpp:0:5 #3 0x01f3c324 SignalHandler(int) /usr/local/google/home/phosek/clang-llvm/llvm/out/lld/../../lib/Support/Unix/Signals.inc:252:1 #4 0x2ba457431330 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330) #5 0x2ba4586e3c37 gsignal /build/eglibc-MjiXCM/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #6 0x2ba4586e7028 abort /build/eglibc-MjiXCM/eglibc-2.19/stdlib/abort.c:91:0
[llvm-bugs] [Bug 33212] PPC vec_cst useless at -O0
https://bugs.llvm.org/show_bug.cgi?id=33212 jt...@ca.ibm.com changed: What|Removed |Added Status|ASSIGNED|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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33456] wrong code with "opt -early-cse-memssa -instcombine -jump-threading -mem2reg -newgvn" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=33456 Daniel Berlin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Daniel Berlin --- r305416 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33457] wrong code with "opt -early-cse-memssa -instcombine -jump-threading -newgvn" on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=33457 Daniel Berlin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Daniel Berlin --- r305416 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33463] New: [Aarch64/ELF] lld doesn't support "--fix-cortex-a53-843419"
https://bugs.llvm.org/show_bug.cgi?id=33463 Bug ID: 33463 Summary: [Aarch64/ELF] lld doesn't support "--fix-cortex-a53-843419" Product: lld Version: unspecified Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: compn...@compnerd.org CC: llvm-bugs@lists.llvm.org This flag is meant to work around an errata in an earlier tape out. At the very least, we should eat this flag to be compatible with gold/bfd. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33464] New: [polly] Assertion `DT.dominates(I->getParent(), L->getHeader()) && "No dominance relationship between SCEV and loop?"' failed. with invariant load hoisting
https://bugs.llvm.org/show_bug.cgi?id=33464
Bug ID: 33464
Summary: [polly] Assertion `DT.dominates(I->getParent(),
L->getHeader()) && "No dominance relationship between
SCEV and loop?"' failed. with invariant load hoisting
Product: Polly
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Optimizer
Assignee: polly-...@googlegroups.com
Reporter: efrie...@codeaurora.org
CC: llvm-bugs@lists.llvm.org
Testcase:
void a(int y, int *p, int *j) {
if (y)
for (int i = 0; i < 1; ++i)
p[*j+i] = i;
else
for (int i = 0; i < 1; ++i)
p[*j+i] = i*2;
}
Compiling with "clang -mllvm -polly -mllvm -polly-process-unprofitable -mllvm
-polly-invariant-load-hoisting --target=aarch64 -mllvm
-polly-position=before-vectorizer -O2", produces the following crash:
clang-4.0: (src)/llvm/lib/Analysis/ScalarEvolution.cpp:2201: bool
llvm::ScalarEvolution::isAvailableAtLoopEntry(const llvm::SCEV *, const
llvm::Loop *)::FindDominatedSCEVUnknown::checkSCEVUnknown(const
llvm::SCEVUnknown *): Assertion `DT.dominates(I->getParent(), L->getHeader())
&& "No dominance relationship between SCEV and loop?"' failed.
#0 0x01f5b704 PrintStackTraceSignalHandler(void*)
((src)/llvm/bin/clang-4.0+0x1f5b704)
#1 0x01f5b966 SignalHandler(int) ((src)/llvm/bin/clang-4.0+0x1f5b966)
#2 0x7f303a6de330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x7f30390cfc37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x7f30390d3028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#5 0x7f30390c8bf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#6 0x7f30390c8ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x0161505a
llvm::SCEVTraversal::push(llvm::SCEV const*)
((src)/llvm/bin/clang-4.0+0x161505a)
#8 0x015d8d9d llvm::ScalarEvolution::isAvailableAtLoopEntry(llvm::SCEV
const*, llvm::Loop const*) ((src)/llvm/bin/clang-4.0+0x15d8d9d)
#9 0x015cf88f
llvm::ScalarEvolution::getAddExpr(llvm::SmallVectorImpl&,
llvm::SCEV::NoWrapFlags, unsigned int) ((src)/llvm/bin/clang-4.0+0x15cf88f)
#10 0x02689ea8
llvm::SCEVRewriteVisitor::visitAddExpr(llvm::SCEVAddExpr
const*) ((src)/llvm/bin/clang-4.0+0x2689ea8)
#11 0x02689b1e
llvm::SCEVRewriteVisitor::visit(llvm::SCEV
const*) ((src)/llvm/bin/clang-4.0+0x2689b1e)
#12 0x02689c49 llvm::SCEVVisitor::visit(llvm::SCEV const*)
((src)/llvm/bin/clang-4.0+0x2689c49)
#13 0x02689b1e
llvm::SCEVRewriteVisitor::visit(llvm::SCEV
const*) ((src)/llvm/bin/clang-4.0+0x2689b1e)
#14 0x026763e5 polly::Scop::getIdForParam(llvm::SCEV const*)
((src)/llvm/bin/clang-4.0+0x26763e5)
#15 0x026c5566 polly::SCEVAffinator::visit(llvm::SCEV const*)
((src)/llvm/bin/clang-4.0+0x26c5566)
#16 0x02671ddb polly::Scop::getPwAff(llvm::SCEV const*,
llvm::BasicBlock*, bool) ((src)/llvm/bin/clang-4.0+0x2671ddb)
#17 0x026707dc
polly::MemoryAccess::buildAccessRelation(polly::ScopArrayInfo const*)
((src)/llvm/bin/clang-4.0+0x26707dc)
#18 0x02672911 polly::ScopStmt::buildAccessRelations()
((src)/llvm/bin/clang-4.0+0x2672911)
#19 0x02673f60 polly::ScopStmt::init(llvm::LoopInfo&)
((src)/llvm/bin/clang-4.0+0x2673f60)
#20 0x026970de polly::ScopBuilder::buildScop(llvm::Region&,
llvm::AssumptionCache&) ((src)/llvm/bin/clang-4.0+0x26970de)
#21 0x02697bd9 polly::ScopBuilder::ScopBuilder(llvm::Region*,
llvm::AssumptionCache&, llvm::AAResults&, llvm::DataLayout const&,
llvm::DominatorTree&, llvm::LoopInfo&, polly::ScopDetection&,
llvm::ScalarEvolution&) ((src)/llvm/bin/clang-4.0+0x2697bd9)
#22 0x02687749 polly::ScopInfoRegionPass::runOnRegion(llvm::Region*,
llvm::RGPassManager&) ((src)/llvm/bin/clang-4.0+0x2687749)
#23 0x015c2c53 llvm::RGPassManager::runOnFunction(llvm::Function&)
((src)/llvm/bin/clang-4.0+0x15c2c53)
#24 0x01a38764 llvm::FPPassManager::runOnFunction(llvm::Function&)
((src)/llvm/bin/clang-4.0+0x1a38764)
#25 0x01a389b3 llvm::FPPassManager::runOnModule(llvm::Module&)
((src)/llvm/bin/clang-4.0+0x1a389b3)
#26 0x01a38ef3 llvm::legacy::PassManagerImpl::run(llvm::Module&)
((src)/llvm/bin/clang-4.0+0x1a38ef3)
#27 0x02110ebb clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::__1::unique_ptr >)
((src)/llvm/bin/clang-4.0+0x2110ebb)
#28 0x0273cebc
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
((src)/llvm/bin/clang-4.0+0x273cebc)
#29 0x029da125 clang::ParseAST(clang::Sema&, bool, bool)
((src)/llvm/bin/clang-4.
[llvm-bugs] [Bug 33465] New: llvm-cov: the '||' operator in an assign statement lead to the statement marked as unexecuted
https://bugs.llvm.org/show_bug.cgi?id=33465
Bug ID: 33465
Summary: llvm-cov: the '||' operator in an assign statement
lead to the statement marked as unexecuted
Product: clang
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: yangyib...@nju.edu.cn
CC: llvm-bugs@lists.llvm.org
Left part of the '||' operator in an assign statement is executed but the right
part is not executed.
This will lead the assign statement being marked as unexecuted in the llvm-cov.
$ clang-5.0 -O0 -fcoverage-mapping -fprofile-instr-generate=small.profraw
small.c -o small
$ llvm-profdata-5.0 merge -o small.profdata small.profraw
$ llvm-cov-5.0 show small -instr-profile=small.profdata small.c > small.gcov
/* small.c */
$ cat small.c
void main()
{
int g, v = 1;
g = v || !v;
return;
}
/* small.gcov */
$ cat small.gcov
1| |void main()
2| 1|{
3| 1|int g, v = 1;
4| 0|g = v || !v;
5| 1|return;
6| 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
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33466] New: Clang crashes with -fblocks when _NSConcrete*Block arrays are not explicitly zeroed out
https://bugs.llvm.org/show_bug.cgi?id=33466
Bug ID: 33466
Summary: Clang crashes with -fblocks when _NSConcrete*Block
arrays are not explicitly zeroed out
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: r...@qumulo.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18641
--> https://bugs.llvm.org/attachment.cgi?id=18641&action=edit
This is the source that caused the crash
I've been experimenting with providing my own implementation of the blocks
runtime and in my runtime I have code like follows which the compiler seems to
need exist when you use blocks:
void * _NSConcreteStackBlock[32];
void * _NSConcreteGlobalBlock[32];
When I did this, sometimes the compiler would crash (I've included the stack
below)
If I change these variables to instead be:
void * _NSConcreteStackBlock[32] = { 0 };
void * _NSConcreteGlobalBlock[32] = { 0 };
the crash goes away.
I've included the source code I compiled as an attachment.
I'm compiling this on Ubuntu 17.04 and this is my clang version:
clang version 4.0.0-1ubuntu1 (tags/RELEASE_400/rc1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
To compile the source I just ran:
/usr/bin/clang -fblocks blocks_crash.c
#0 0x7fd8d6c73488 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1+0x6ee488)
#1 0x7fd8d6c7156e llvm::sys::RunSignalHandlers()
(/usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1+0x6ec56e)
#2 0x7fd8d6c716aa (/usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1+0x6ec6aa)
#3 0x7fd8d94f1670 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x11670)
#4 0x7fd8d6d753d4 llvm::Value::getContext() const
(/usr/lib/llvm-4.0/bin/../lib/libLLVM-4.0.so.1+0x7f03d4)
#5 0x7fd8d6caec04
llvm::ConstantStruct::getTypeForElements(llvm::ArrayRef, bool)
(/usr/lib/llvm-4.0/bin/../lib/lib
LLVM-4.0.so.1+0x729c04)
#6 0x56373fe94908 (/usr/lib/llvm-4.0/bin/clang+0x697908)
#7 0x56373fe94d0a
clang::CodeGen::CodeGenModule::GetAddrOfGlobalBlock(clang::BlockExpr const*,
llvm::StringRef) (/usr/lib/llvm-4.0/
bin/clang+0x697d0a)
#8 0x56373fda2fec (/usr/lib/llvm-4.0/bin/clang+0x5a5fec)
#9 0x56373fda397d
clang::CodeGen::CodeGenModule::EmitConstantValue(clang::APValue const&,
clang::QualType, clang::CodeGen::CodeGenF
unction*) (/usr/lib/llvm-4.0/bin/clang+0x5a697d)
#10 0x56373fda40ef
clang::CodeGen::CodeGenModule::EmitConstantValueForMemory(clang::APValue
const&, clang::QualType, clang::CodeGen
::CodeGenFunction*) (/usr/lib/llvm-4.0/bin/clang+0x5a70ef)
#11 0x56373fda694b
clang::CodeGen::CodeGenModule::EmitConstantInit(clang::VarDecl const&,
clang::CodeGen::CodeGenFunction*) (/usr/l
ib/llvm-4.0/bin/clang+0x5a994b)
#12 0x56373fdfa2cc
clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*,
bool) (/usr/lib/llvm-4.0/bin/clang
+0x5fd2cc)
#13 0x56373fe0f0bb
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl,
llvm::GlobalValue*) (/usr/lib/llvm-4.0/bi
n/clang+0x6120bb)
#14 0x56373fe0f30e clang::CodeGen::CodeGenModule::EmitDeferred()
(/usr/lib/llvm-4.0/bin/clang+0x61230e)
#15 0x56373fe0f3e4 clang::CodeGen::CodeGenModule::Release()
(/usr/lib/llvm-4.0/bin/clang+0x6123e4)
#16 0x5637401cfd27 (/usr/lib/llvm-4.0/bin/clang+0x9d2d27)
#17 0x5637401cf695 (/usr/lib/llvm-4.0/bin/clang+0x9d2695)
#18 0x5637402f15e8 clang::ParseAST(clang::Sema&, bool, bool)
(/usr/lib/llvm-4.0/bin/clang+0xaf45e8)
#19 0x5637400a990e clang::FrontendAction::Execute()
(/usr/lib/llvm-4.0/bin/clang+0x8ac90e)
#20 0x56374007a6f6
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/usr/lib/llvm-4.0/bin/clang+0x87d6f6)
#21 0x56374012bcd3
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/usr/lib/llvm-4.0/bin/clang+0x92ecd3)
#22 0x56373fd404d8 cc1_main(llvm::ArrayRef, char const*,
void*) (/usr/lib/llvm-4.0/bin/clang+0x5434d8)
#23 0x56373fd31576 main (/usr/lib/llvm-4.0/bin/clang+0x534576)
#24 0x7fd8d57043f1 __libc_start_main
/build/glibc-cxyGtm/glibc-2.24/csu/../csu/libc-start.c:325:0
#25 0x56373fd3e72a _start (/usr/lib/llvm-4.0/bin/clang+0x54172a)
Stack dump:
0. Program arguments: /usr/lib/llvm-4.0/bin/clang -cc1 -triple
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-ll
vm-verifier -discard-value-names -main-file-name blocks_crash.c
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath
-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb
-resource-dir /usr/lib/llvm-4.0/bin/../lib/clang/4.0.0 -internal-isystem
/usr/local/include -internal-isystem /usr/lib/llvm-4.0/bin/../
lib/clang/4.0.0/include -internal-externc-isystem /usr/incl
[llvm-bugs] [Bug 32318] -ast-dump-all crashes on empty files
https://bugs.llvm.org/show_bug.cgi?id=32318 Don Hinton changed: What|Removed |Added Status|NEW |RESOLVED CC||hinto...@gmail.com Assignee|unassignedclangbugs@nondot. |hinto...@gmail.com |org | Resolution|--- |FIXED --- Comment #1 from Don Hinton --- Fix committed here r305432. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33467] New: Floating point to integer conversion for Java-like languages
https://bugs.llvm.org/show_bug.cgi?id=33467
Bug ID: 33467
Summary: Floating point to integer conversion for Java-like
languages
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: serguei.kat...@azul.com
CC: llvm-bugs@lists.llvm.org
There are languages like Java where the floating pointer conversion to integer
is strictly defined in case fp value does not fit int range.
Specifically Java semantic can be represented by the following C++ function:
int test1(float f) {
if (f != f) // NaN
return 0;
if (f > (float)std::numeric_limits::max())
return std::numeric_limits::max();
if (f < (float)std::numeric_limits::min())
return std::numeric_limits::min();
return (int)f;
}
Currently this results in the following X86 assembler code:
<_Z5test1f>:
0: 0f 2e c0ucomiss %xmm0,%xmm0
3: 7a 25 jp 2a <_Z5test1f+0x2a>
5: b8 ff ff ff 7f mov$0x7fff,%eax
a: 0f 2e 05 00 00 00 00ucomiss 0x0(%rip),%xmm0# 11
<_Z5test1f+0x11>
11: 77 16 ja 29 <_Z5test1f+0x29>
13: b8 00 00 00 80 mov$0x8000,%eax
18: f3 0f 10 0d 00 00 00movss 0x0(%rip),%xmm1# 20
<_Z5test1f+0x20>
1f: 00
20: 0f 2e c8ucomiss %xmm0,%xmm1
23: 77 04 ja 29 <_Z5test1f+0x29>
25: f3 0f 2c c0 cvttss2si %xmm0,%eax
29: c3 retq
2a: 31 c0 xor%eax,%eax
2c: c3 retq
So to do a fp conversion to int we should execute 3 checks for conversion
really happens while all checks actually are for corner cases when fp value is
NaN or does not fit int range.
However X86 instruction cvttss2si has an additional property. It returns
INT_MIN in case fp value does not fit the int range.
So the better generated code would be something like this:
<_Z4testf>:
0: f3 0f 2c c0 cvttss2si %xmm0,%eax
4: 3d 00 00 00 80 cmp$0x8000,%eax
9: 75 17 jne22 <_Z4testf+0x22>
b: 0f 2e c0ucomiss %xmm0,%xmm0
e: 7a 13 jp 23 <_Z4testf+0x23>
10: b8 00 00 00 80 mov$0x8000,%eax
15: 0f 57 c9xorps %xmm1,%xmm1
18: 0f 2e c1ucomiss %xmm1,%xmm0
1b: 76 05 jbe22 <_Z4testf+0x22>
1d: b8 ff ff ff 7f mov$0x7fff,%eax
22: c3 retq
23: 31 c0 xor%eax,%eax
25: c3 retq
where we need only one check to generate the most common case.
Or even better if we could put the fast pass right after first conversion.
It would be nice if X86 backend could catch this pattern to utilize the
addition property of conversion instruction.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
