[llvm-bugs] [Bug 27126] New: clang crashes on C++ code with oversized bit-field
https://llvm.org/bugs/show_bug.cgi?id=27126 Bug ID: 27126 Summary: clang crashes on C++ code with oversized bit-field Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified The current clang trunk (as well 3.5.x and later) crashes when compiling the following C++ test case on x86_64-linux-gnu in both 32-bit and 64-bit modes. This is a regression from 3.4.x. $ clang++ -v clang version 3.9.0 (trunk 264702) 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/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.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.3 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.3.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang++ -c small.cpp small.cpp:4:12: warning: width of bit-field 'f' (1000 bits) exceeds the width of its type; value will be truncated to 32 bits [-Wbitfield-width] unsigned f : 1000; ^ clang-3.9: /tmp/llvm-builder/llvm-source-trunk/lib/IR/Type.cpp:251: static llvm::IntegerType* llvm::IntegerType::get(llvm::LLVMContext&, unsigned int): Assertion `NumBits <= MAX_INT_BITS && "bitwidth too large"' failed. #0 0x01d5d365 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-3.9+0x1d5d365) #1 0x01d5b2f6 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-3.9+0x1d5b2f6) #2 0x01d5b514 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-3.9+0x1d5b514) #3 0x7f82c1585340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f82c07a3cc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f82c07a70d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f82c079cb86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #7 0x7f82c079cc32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x01a1301a llvm::IntegerType::get(llvm::LLVMContext&, unsigned int) (/usr/local/clang-trunk/bin/clang-3.9+0x1a1301a) #9 0x01ecac8e (anonymous namespace)::CGRecordLowering::accumulateFields() (/usr/local/clang-trunk/bin/clang-3.9+0x1ecac8e) #10 0x01ecf532 (anonymous namespace)::CGRecordLowering::lower(bool) (/usr/local/clang-trunk/bin/clang-3.9+0x1ecf532) #11 0x01ed1a46 clang::CodeGen::CodeGenTypes::ComputeRecordLayout(clang::RecordDecl const*, llvm::StructType*) (/usr/local/clang-trunk/bin/clang-3.9+0x1ed1a46) #12 0x01f5a38e clang::CodeGen::CodeGenTypes::ConvertRecordDeclType(clang::RecordDecl const*) (/usr/local/clang-trunk/bin/clang-3.9+0x1f5a38e) #13 0x01f5bb6d clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) (/usr/local/clang-trunk/bin/clang-3.9+0x1f5bb6d) #14 0x01fd7d4c clang::CodeGen::CodeGenTypes::GetFunctionType(clang::CodeGen::CGFunctionInfo const&) (/usr/local/clang-trunk/bin/clang-3.9+0x1fd7d4c) #15 0x01f2adac clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/usr/local/clang-trunk/bin/clang-3.9+0x1f2adac) #16 0x01f38221 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/usr/local/clang-trunk/bin/clang-3.9+0x1f38221) #17 0x01f39114 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/usr/local/clang-trunk/bin/clang-3.9+0x1f39114) #18 0x01f3965d clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.6083] (/usr/local/clang-trunk/bin/clang-3.9+0x1f3965d) #19 0x024b479c (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (/usr/local/clang-trunk/bin/clang-3.9+0x24b479c) #20 0x024af36c clang::BackendConsumer::HandleTopLevelDecl(clang::
[llvm-bugs] [Bug 27127] New: [Polly] Miscompilation in LNT with r264789, -polly-position=before-vectorizer and -polly-process-unprofitable
https://llvm.org/bugs/show_bug.cgi?id=27127 Bug ID: 27127 Summary: [Polly] Miscompilation in LNT with r264789, -polly-position=before-vectorizer and -polly-process-unprofitable Product: Polly Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: Optimizer Assignee: polly-...@googlegroups.com Reporter: gareevro...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified With r264789 'clang -O3 -mllvm -polly -mllvm -polly-position=before-vectorizer -mllvm -polly-process-unprofitable' results in miscompiles of the LNT benchmarks ControlFlow-flt and ControlFlow-dbl. -- 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 27016] segfault in Writer::copyLocalSymbols() building FreeBSD/i386 with lld, due to local undefined symbol
https://llvm.org/bugs/show_bug.cgi?id=27016 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from George Rimar --- r264843 -- 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 23214] [META] Using LLD as FreeBSD's system linker
https://llvm.org/bugs/show_bug.cgi?id=23214 Bug 23214 depends on bug 27016, which changed state. Bug 27016 Summary: segfault in Writer::copyLocalSymbols() building FreeBSD/i386 with lld, due to local undefined symbol https://llvm.org/bugs/show_bug.cgi?id=27016 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 27128] New: PowerPC64: jump tables cause failure during early Linux boot
https://llvm.org/bugs/show_bug.cgi?id=27128 Bug ID: 27128 Summary: PowerPC64: jump tables cause failure during early Linux boot Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: an...@samba.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified A recent patch to more aggressively use jump tables ([Codegen] Decrease minimum jump table density) has shown up an issue when using llvm to build the PowerPC64 Linux kernel. The kernel spends a short amount of time in early boot running at a non zero offset. We do this by relocating everything in the TOC, then undoing that when we copy ourselves down to 0. We don't have an issue with jump tables on gcc because they use 32bit offsets which get added to a base address. On llvm they are 64bit addresses. Looking closer, it looks like llvm emits similar code to gcc when using the -fpic flag. We've avoided the complexity and overhead of building a completely relocatable image so far, perhaps we need to revisit that. -- 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 27018] "Unhandled instruction type!" UNREACHABLE when building Chromium for ARM
https://llvm.org/bugs/show_bug.cgi?id=27018 James Molloy changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from James Molloy --- Hi Nico, This should be fixed in r264852. Cheers, James -- 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 27129] New: Template alias crashes template diffing
https://llvm.org/bugs/show_bug.cgi?id=27129
Bug ID: 27129
Summary: Template alias crashes template diffing
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: crash-on-invalid
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: benny@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org,
rtr...@google.com
Classification: Unclassified
$ cat crash.cc
template
class vector {};
template
class Point;
template
using Polygon = vector>;
void foo(Polygon<3, float>);
void bar() { foo(Polygon<2, float>()); }
$ clang crash.cc -std=c++11
crash.cc:10:14: error: no matching function for call to 'foo'
void bar() { foo(Polygon<2, float>()); }
^~~
unknown ArgumentKind
UNREACHABLE executed at llvm/tools/clang/lib/AST/ASTDiagnostic.cpp:1169!
--
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 27130] New: MC produces a local symbol, gas a global
https://llvm.org/bugs/show_bug.cgi?id=27130 Bug ID: 27130 Summary: MC produces a local symbol, gas a global Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16128 --> https://llvm.org/bugs/attachment.cgi?id=16128&action=edit test -- 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 27131] New: -Wincompatible-pointer-types treats constnat strings as NSString even when -fconstant-string-class is used
https://llvm.org/bugs/show_bug.cgi?id=27131 Bug ID: 27131 Summary: -Wincompatible-pointer-types treats constnat strings as NSString even when -fconstant-string-class is used Product: clang Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: p...@twisted.org.uk CC: llvm-bugs@lists.llvm.org Classification: Unclassified When using an alternative class for constant strings (i.e. I am not using OS X or GNUStep ) then warning for incompatible types are generated, which appear to be based on still using NSString as the class of the constant string. For example this code: MyConstStr *s; s = @"foo"; will generate this error test.m:21:7: warning: incompatible pointer types assigning to 'MyConstStr *' from 'NSString *' [-Wincompatible-pointer-types] s = @"foo"; This works fine under gcc 4 and 5. Note that the resulting code works fine, it is just the warning which is wrong. -- 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 27132] New: Need MSVC manging for __unaligned qualifiers
https://llvm.org/bugs/show_bug.cgi?id=27132
Bug ID: 27132
Summary: Need MSVC manging for __unaligned qualifiers
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: andreybokha...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Clang doesn't mangle MS-specific __unaligned qualifier:
$ cat H:/test.cpp
int __unaligned * foo1() { return 0; }
MS compiler:
$ cl.exe H:/test.cpp -c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
test.cpp
$ dumpbin /symbols test.obj
Microsoft (R) COFF/PE Dumper Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file test.obj
...
008 SECT3 notype ()External | ?foo1@@YAPEFAHXZ (int
__unaligned * __cdecl foo1(void))
Clang:
$ clang-cl H:/test.cpp -c
$ dumpbin /symbols test.obj
Microsoft (R) COFF/PE Dumper Version 12.00.31101.0
Copyright (C) Microsoft Corporation. All rights reserved
Dump of file test.obj
...
00C SECT1 notype ()External | ?foo1@@YAPEAHXZ (int * __cdecl
foo1(void))
(note there is no 'F' in Clang version)
Yours,
Andrey
=
Software Engineer
Intel Compiler Team
--
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 27133] New: clang-cl: LLVM lib/Transforms/Scalar/IndVarSimplify.cpp WidenIV::widenIVUse: dereference getFirstInsertionPt() == end()
https://llvm.org/bugs/show_bug.cgi?id=27133
Bug ID: 27133
Summary: clang-cl: LLVM
lib/Transforms/Scalar/IndVarSimplify.cpp
WidenIV::widenIVUse: dereference getFirstInsertionPt()
== end()
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: stephan.bergmann.second...@googlemail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
At least on recent trunk r264857, attached (non-reduced) reproducer crashes
clang-cl, as
IRBuilder<> Builder(&*WidePhi->getParent()->getFirstInsertionPt());
in WidenIV::widenIVUse (LLVM lib/Transforms/Scalar/IndVarSimplify.cpp)
dereferences an at-the-end iterator.
With
> --- a/lib/Transforms/Scalar/IndVarSimplify.cpp
> +++ b/lib/Transforms/Scalar/IndVarSimplify.cpp
> @@ -1287,7 +1287,10 @@ Instruction *WidenIV::widenIVUse(NarrowIVDefUse DU,
> SCEVExpander &Rewriter) {
>PHINode::Create(DU.WideDef->getType(), 1, UsePhi->getName() +
> ".wide",
>UsePhi);
> WidePhi->addIncoming(DU.WideDef, UsePhi->getIncomingBlock(0));
> -IRBuilder<> Builder(&*WidePhi->getParent()->getFirstInsertionPt());
> +auto bb = WidePhi->getParent();
> +auto i = bb->getFirstInsertionPt();
> +assert(i != bb->end());
> +IRBuilder<> Builder(&*i);
> Value *Trunc = Builder.CreateTrunc(WidePhi, DU.NarrowDef->getType());
> UsePhi->replaceAllUsesWith(Trunc);
> DeadInsts.emplace_back(UsePhi);
the assertion fires at
> __GI___assert_fail at assert.c:101
> (anonymous namespace)::WidenIV::widenIVUse at
> llvm/lib/Transforms/Scalar/IndVarSimplify.cpp:1292
> (anonymous namespace)::WidenIV::createWideIV at
> llvm/lib/Transforms/Scalar/IndVarSimplify.cpp:1474
> (anonymous namespace)::IndVarSimplify::simplifyAndExtend at
> llvm/lib/Transforms/Scalar/IndVarSimplify.cpp:1561
> (anonymous namespace)::IndVarSimplify::runOnLoop at
> llvm/lib/Transforms/Scalar/IndVarSimplify.cpp:2168
> llvm::LPPassManager::runOnFunction at llvm/lib/Analysis/LoopPass.cpp:198
> llvm::FPPassManager::runOnFunction at llvm/lib/IR/LegacyPassManager.cpp:1550
> (anonymous namespace)::CGPassManager::RunPassOnSCC at
> llvm/lib/Analysis/CallGraphSCCPass.cpp:150
> (anonymous namespace)::CGPassManager::RunAllPassesOnSCC at
> llvm/lib/Analysis/CallGraphSCCPass.cpp:419
> (anonymous namespace)::CGPassManager::runOnModule at
> llvm/lib/Analysis/CallGraphSCCPass.cpp:474
> (anonymous namespace)::MPPassManager::runOnModule at
> llvm/lib/IR/LegacyPassManager.cpp:1627
> llvm::legacy::PassManagerImpl::run at llvm/lib/IR/LegacyPassManager.cpp:1730
> llvm::legacy::PassManager::run at llvm/lib/IR/LegacyPassManager.cpp:1761
> (anonymous namespace)::EmitAssemblyHelper::EmitAssembly at
> llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:702
> clang::EmitBackendOutput at llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:719
> clang::BackendConsumer::HandleTranslationUnit at
> llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:178
> clang::ParseAST at llvm/tools/clang/lib/Parse/ParseAST.cpp:168
> clang::ASTFrontendAction::ExecuteAction at
> llvm/tools/clang/lib/Frontend/FrontendAction.cpp:557
> clang::CodeGenAction::ExecuteAction at
> llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:822
> clang::FrontendAction::Execute at
> llvm/tools/clang/lib/Frontend/FrontendAction.cpp:457
> clang::CompilerInstance::ExecuteAction at
> llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:873
> clang::ExecuteCompilerInvocation at
> llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:241
> cc1_main at llvm/tools/clang/tools/driver/cc1_main.cpp:116
> ExecuteCC1Tool at llvm/tools/clang/tools/driver/driver.cpp:301
> main at llvm/tools/clang/tools/driver/driver.cpp:366
--
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 27135] New: SelectionDAGBuilder::visitSwitch() creates disconnected MBB
https://llvm.org/bugs/show_bug.cgi?id=27135 Bug ID: 27135 Summary: SelectionDAGBuilder::visitSwitch() creates disconnected MBB Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: co...@google.com, h...@hanshq.net, llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16130 --> https://llvm.org/bugs/attachment.cgi?id=16130&action=edit Input for compilation visitSwitch() seems to create an MBB whithout predecessors / successors. The attached test case is not minimized, but the verifier gives the exact spot. If you are lucky, you can get there in gdb with: b MachineFunction:247 // in CreateMachineBasicBlock() condition [BP] (bb && strcmp(bb->getName().Data,"if.then72")==0) c // continue once u // go up the stack a few times, and that should be the SelectionDAGBuilder handling bb: if.then72:; preds = %land.lhs.true71 %24 = inttoptr i64 %in.addr.sroa.0.0 to %struct.rtx_def* %arrayidx74 = getelementptr inbounds %struct.rtx_def, %struct.rtx_def* %24, i64 0, i32 1, i64 0 %25 = bitcast %union.rtunion_def* %arrayidx74 to i32** %26 = load i32*, i32** %25, align 8, !tbaa !5 %bf.load75 = load i32, i32* %26, align 8 %bf.lshr76 = lshr i32 %bf.load75, 16 switch i32 %bf.lshr76, label %if.end92 [ i32 99, label %sw.bb i32 98, label %sw.bb i32 101, label %sw.bb i32 97, label %sw.bb84 i32 96, label %sw.bb84 i32 100, label %sw.bb84 ] (gdb) run -cc1 -triple s390x-ibm-linux -S -disable-free -main-file-name reload.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu z13 -momit-leaf-frame-pointer -v -dwarf-column-info -debugger-tuning=gdb -O3 -ferror-limit 19 -fmessage-length 238 -funroll-loops -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o reload.s -x ir ./reload.bc Add -mllvm -verify-machineinstrs to see the error message: ... BB#524: derived from LLVM BB %if.then72 Predecessors according to CFG: BB#17 %vreg455 = LHIMux 1; GR32Bit:%vreg455 %vreg456 = SLL %vreg455, %vreg453, 0; GR32Bit:%vreg456,%vreg455 ADDR32Bit:%vreg453 TMLMux %vreg456, 19, %CC; GR32Bit:%vreg456 BRC 15, 7, , %CC J Successors according to CFG: BB#19(0x4000 / 0x8000 = 50.00%) BB#18(0x4000 / 0x8000 = 50.00%) BB#525: derived from LLVM BB %if.then72 < Not connected!! BB#18: derived from LLVM BB %sw.bb ... *** Bad machine code: PHI operand is not in the CFG *** - function:push_reload - basic block: BB#20 if.end92 (0x85a2f140) - instruction: %vreg17 = PHI - operand 16: *** Bad machine code: PHI operand is not in the CFG *** - function:push_reload - basic block: BB#20 if.end92 (0x85a2f140) - instruction: %vreg18 = PHI - operand 16: fatal error: error in backend: Found 2 machine code errors. -- 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 27127] [Polly] Miscompilation in LNT with r264789, -polly-position=before-vectorizer and -polly-process-unprofitable
https://llvm.org/bugs/show_bug.cgi?id=27127 Tobias Grosser changed: 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27136] New: Failure to hoist constant out of loop
https://llvm.org/bugs/show_bug.cgi?id=27136
Bug ID: 27136
Summary: Failure to hoist constant out of loop
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: chisophu...@gmail.com, llvm-bugs@lists.llvm.org,
spatel+l...@rotateright.com
Classification: Unclassified
Poor code gen identified in Andreas Fredriksson's GDC 2016 Talk 'Taming the
Jaguar: x86 Optimization at Insomniac Games':
http://schedule.gdconf.com/session/taming-the-jaguar-x86-optimization-at-insomniac-games
search.c:
#include
#include
bool search(uint32_t needle, const uint32_t *haystack, int count) {
for (int i = 0; i < count; ++i)
if (needle == haystack[i])
return true;
return false;
}
clang -O3 -S -march=btver2 search.c -o -
_search:
.cfi_startproc
## BB#0:
pushq%rbp
Ltmp0:
.cfi_def_cfa_offset 16
Ltmp1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Ltmp2:
.cfi_def_cfa_register %rbp
testl%edx, %edx
jleLBB0_1
## BB#4:
movslq%edx, %rcx
xorl%edx, %edx
.p2align4, 0x90
LBB0_5:
cmpl%edi, (%rsi,%rdx,4)
movb$1, %al
jeLBB0_6
## BB#2:
incq%rdx
cmpq%rcx, %rdx
jlLBB0_5
## BB#3:
xorl%eax, %eax
popq%rbp
retq
LBB0_1:
xorl%eax, %eax
popq%rbp
retq
LBB0_6:
popq%rbp
retq
.cfi_endproc
As well as failing to pull the "movb $1, %al" out of the loop (and avoid the
partial register move issue), it also fails to merge the 3 epilogs into
something like:
## BB#3:
LBB0_1:
xorl%eax, %eax
LBB0_6:
popq%rbp
retq
--
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 27137] New: wrong code at -O2 and -O3 in both 32-bit and 64-bit mode on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=27137
Bug ID: 27137
Summary: wrong code at -O2 and -O3 in both 32-bit and 64-bit
mode on x86_64-linux-gnu
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: chengnian...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code is miscompiled by the clang trunk at -O2 and -O3 in both
32-bit and 64-bit modes on x86_64-linux-gnu.
This bug also affects clang-3.7 and clang-3.8.
$: clang-trunk -v
clang version 3.9.0 (trunk 264841)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.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.3
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.3.0
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.3
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.4
Found candidate GCC installation:
/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$:
$: clang-trunk -O3 small.c ; ./a.out
1
$: clang-trunk -O1 small.c ; ./a.out
-28
$:
$: clang-3.7 -O3 small.c ; ./a.out
1
$: cat small.c
int printf(const char *, ...);
int a, c;
char b;
int main() {
short d = -28;
for (; a; a--)
if (b) {
int e = d / 4;
d = e + 8;
}
c = 0;
for (; c < 10; c++)
while (d > 1)
d--;
printf("%d\n", d);
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 23698] [win] compiler_rt doesn't link when building with clang-cl.exe
https://llvm.org/bugs/show_bug.cgi?id=23698 Reid Kleckner changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Reid Kleckner --- There's more issues here. I just tried building asan with clang-cl and it went poorly. By making unknown arguments in clang-cl into warnings instead of errors, all of the check_cxx_compiler_flag checks in compiler-rt return true for clang-cl. I filed https://cmake.org/Bug/view.php?id=16038 to get this fixed in cmake, but we might need to do something to support common versions of cmake. -- 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 26558] Inconsistency with ADX intrinsics and builtins requirements
https://llvm.org/bugs/show_bug.cgi?id=26558 Yunzhong Gao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Yunzhong Gao --- Committed in r264801. -- 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 27138] New: PowerPC code gen bug in 3.8. invalid elimination of store
https://llvm.org/bugs/show_bug.cgi?id=27138 Bug ID: 27138 Summary: PowerPC code gen bug in 3.8. invalid elimination of store Product: new-bugs Version: 3.8 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: eric.schwe...@pgroup.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16132 --> https://llvm.org/bugs/attachment.cgi?id=16132&action=edit code that exposes a store elimination bug The bugged .ll example shows a floating-point value of 4.0 being stored, loaded, and multiplied by 0.2. The value 0.8 is then printed as output by LLVM 3.7. In LLVM 3.8, the output is 0.0. It appears that the store of 4.0 is erroneously eliminated. To expose the bug the following commands were used: llc -O0 -o bug.s bug.ll as bug.s -o bug.o clang bug.o -O0 -o bug.out ./bug.out 0.00 -- 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 26837] Availability of SSE detrimental to code performance
https://llvm.org/bugs/show_bug.cgi?id=26837 Hal Finkel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Hal Finkel --- (In reply to comment #34) > Thanks, next time I've built rustc it will have been with this patch. I'll > let you know about the result in a few days. Committed (with Sanjay's test case from Comment 14) r264904. -- 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 21547] Clang codegen asserts "An asserting value handle still pointed to this value!"
https://llvm.org/bugs/show_bug.cgi?id=21547 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Vassil Vassilev --- Added regression test in r264908. -- 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 16068] Fails to diagnose ambiguous base class
https://llvm.org/bugs/show_bug.cgi?id=16068 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #2 from Richard Smith --- *** This bug has been marked as a duplicate of bug 18834 *** -- 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 24626] clang incorrectly deduces ambiguous template from base class
https://llvm.org/bugs/show_bug.cgi?id=24626 Richard Smith changed: What|Removed |Added Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk Resolution|--- |DUPLICATE --- Comment #1 from Richard Smith --- *** This bug has been marked as a duplicate of bug 18834 *** -- 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 27041] (IdentifierOffsets[I] && "Missing identifier offset?"), function WriteIdentifierTable
https://llvm.org/bugs/show_bug.cgi?id=27041 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vassil Vassilev --- Fixed in r264913. -- 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 27140] New: [X86] Redundant adjacent stack adjustments after call frame optimization
https://llvm.org/bugs/show_bug.cgi?id=27140
Bug ID: 27140
Summary: [X86] Redundant adjacent stack adjustments after call
frame optimization
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org
Blocks: 26299
Classification: Unclassified
For example
void f(int, int);
void g() {
f(1, 2);
}
Compiled with Clang 3.8 for 32-bit x86 Linux at -Os:
g:
subl$12, %esp
subl$8, %esp
pushl $2
pushl $1
calll f
addl$16, %esp
addl$12, %esp
retl
I'm working on a patch.
--
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 26997] memset() is optimised out even if followed by asm("":::"memory")
https://llvm.org/bugs/show_bug.cgi?id=26997
Коренберг Марк changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |---
--- Comment #4 from Коренберг Марк ---
OKAY.
But following program does not work as expected :)
How to fix ? Is this a bug ?
===
#include
static void* memset_s(void* buf, int ch, size_t size) {
void *ret = memset(buf, 0, sizeof(buf));
asm volatile("": : "g" (buf) :"memory");
return ret;
}
int main() {
char buf[256];
memset_s(buf, 0, sizeof(buf));
return buf[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 26997] memset() is optimised out even if followed by asm("":::"memory")
https://llvm.org/bugs/show_bug.cgi?id=26997 Коренберг Марк changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Коренберг Марк --- Sorry. forgot chnging sizeof(buf) to size. After that everything works right *** This bug has been marked as a duplicate of bug 15495 *** -- 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 27141] New: [x86, AVX] vbroadcast not used to splat constant
https://llvm.org/bugs/show_bug.cgi?id=27141
Bug ID: 27141
Summary: [x86, AVX] vbroadcast not used to splat constant
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This was noticed in the output of http://reviews.llvm.org/D18566 (bug 27100):
define void @hoo(<4 x i32>* %x, i8 %c) {
%ins = insertelement <4 x i32> undef, i32 42, i32 0
%splat = shufflevector <4 x i32> %ins, <4 x i32> undef, <4 x i32>
zeroinitializer
store <4 x i32> %splat, <4 x i32>* %x
ret void
}
$ ./llc -o - memset.ll -mattr=avx
...
vmovapsLCPI0_0(%rip), %xmm0## xmm0 = [42,42,42,42]
vmovaps%xmm0, (%rdi)
$ ./llc -o - memset.ll -mattr=avx2
...
vbroadcastssLCPI0_0(%rip), %xmm0
vmovaps%xmm0, (%rdi)
vbroadcastss from memory is available with AVX, so these should produce
identical asm.
--
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 27133] clang-cl: LLVM lib/Transforms/Scalar/IndVarSimplify.cpp WidenIV::widenIVUse: dereference getFirstInsertionPt() == end()
https://llvm.org/bugs/show_bug.cgi?id=27133 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Component|-New Bugs |Loop Optimizer Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | Product|clang |libraries --- Comment #7 from David Majnemer --- Fixed in r264926. -- 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 27142] New: clang crashes on code with struct having fields of incomplete types
https://llvm.org/bugs/show_bug.cgi?id=27142
Bug ID: 27142
Summary: clang crashes on code with struct having fields of
incomplete types
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The current clang trunk (as well 3.5.x and later) crashes when compiling the
following test case on x86_64-linux-gnu in both 32-bit and 64-bit modes.
This is a regression from 3.4.x.
$ clang++ -v
clang version 3.9.0 (trunk 264841)
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/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.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.3
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.3.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang++-3.4 small.cpp
small.cpp:3:5: error: field has incomplete type 'S'
S v;
^
small.cpp:1:8: note: definition of 'S' is not complete until the closing '}'
struct S
^
1 error generated.
$
$ clang++ small.cpp
small.cpp:3:5: error: field has incomplete type 'S'
S v;
^
small.cpp:1:8: note: definition of 'S' is not complete until the closing '}'
struct S
^
clang-3.9: error: unable to execute command: Segmentation fault (core dumped)
clang-3.9: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.9.0 (trunk 264841)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
clang-3.9: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3.9: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3.9: note: diagnostic msg: /tmp/small-0f5af3.cpp
clang-3.9: note: diagnostic msg: /tmp/small-0f5af3.sh
clang-3.9: note: diagnostic msg:
$
---
struct S
{
S v;
} a;
int
main ()
{
__builtin_memset (&a, 0, sizeof a);
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 27143] New: [scheduler] memset stores don't occur from low-to-high addresses
https://llvm.org/bugs/show_bug.cgi?id=27143
Bug ID: 27143
Summary: [scheduler] memset stores don't occur from low-to-high
addresses
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This was noticed in the output of http://reviews.llvm.org/D18566 (bug 27100):
define void @store_32_bytes(i8* %x, i32 %v, i8 %c) {
call void @llvm.memset.p0i8.i32(i8* %x, i8 42, i32 32, i32 1, i1 false)
ret void
}
declare void @llvm.memset.p0i8.i32(i8* nocapture, i8, i32, i32, i1) nounwind
$ ./llc -o - memset.ll
...
movabsq$3038287259199220266, %rax ## imm = 0x2A2A2A2A2A2A2A2A
movq%rax, 24(%rdi)
movq%rax, 16(%rdi)
movq%rax, 8(%rdi)
movq%rax, (%rdi)
The inverted order (high to low address offsets) of the stores from what was
created in the DAG suggests that the scheduler is doing unnecessary work with
no hope of any actual perf improvement.
In the worst case, going backwards through memory might cause a perf regression
for simple HW that only detects forward accesses for prefetching.
This is not an x86-specific bug. I see the same behavior for PPC64 and AArch64.
--
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 27144] New: clang crashes on valid C++ code
https://llvm.org/bugs/show_bug.cgi?id=27144 Bug ID: 27144 Summary: clang crashes on valid C++ code Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: llvm-bugs@lists.llvm.org Classification: Unclassified The current clang trunk (as well 3.2.x and later) crashes when compiling the following test case on x86_64-linux-gnu in both 32-bit and 64-bit modes. This is a regression from 3.1.x. $ clang++ -v clang version 3.9.0 (trunk 264841) 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/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.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.3 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.3.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang++-3.1 -c small.cpp $ $ clang++ -c small.cpp clang-3.9: /tmp/llvm-builder/llvm-source-trunk/tools/clang/lib/AST/ExprClassification.cpp:56: Cl clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const: Assertion `getValueKind() == VK_LValue' failed. #0 0x01d5a075 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-3.9+0x1d5a075) #1 0x01d58006 llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-3.9+0x1d58006) #2 0x01d58224 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-3.9+0x1d58224) #3 0x7f86dd97e340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f86dcb9ccc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f86dcba00d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f86dcb95b86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #7 0x7f86dcb95c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x03276605 clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const (/usr/local/clang-trunk/bin/clang-3.9+0x3276605) #9 0x03276717 clang::Expr::isModifiableLvalue(clang::ASTContext&, clang::SourceLocation*) const (/usr/local/clang-trunk/bin/clang-3.9+0x3276717) #10 0x02b72819 CheckForModifiableLvalue(clang::Expr*, clang::SourceLocation, clang::Sema&) (/usr/local/clang-trunk/bin/clang-3.9+0x2b72819) #11 0x02b89e9e clang::Sema::CheckAssignmentOperands(clang::Expr*, clang::ActionResult&, clang::SourceLocation, clang::QualType) (/usr/local/clang-trunk/bin/clang-3.9+0x2b89e9e) #12 0x02b8b0d7 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2b8b0d7) #13 0x02b8bd0a clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2b8bd0a) #14 0x02b8c02a clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) (/usr/local/clang-trunk/bin/clang-3.9+0x2b8c02a) #15 0x0282ace5 clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult, clang::prec::Level) (/usr/local/clang-trunk/bin/clang-3.9+0x282ace5) #16 0x0282a5e9 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x282a5e9) #17 0x0282a659 clang::Parser::ParseExpression(clang::Parser::TypeCastState) (/usr/local/clang-trunk/bin/clang-3.9+0x282a659) #18 0x028674b6 clang::Parser::ParseExprStatement() (/usr/local/clang-trunk/bin/clang-3.9+0x28674b6) #19 0x0286609f clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedContsructsKind, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) (/usr/local/clang-trunk/bin/clang-3.9+0x286609f) #20 0x028664be clang::
[llvm-bugs] [Bug 26649] buggy adaptive locking case
https://llvm.org/bugs/show_bug.cgi?id=26649 Johnny Peyton changed: What|Removed |Added Status|NEW |RESOLVED CC||jpeyto...@gmail.com Resolution|--- |FIXED --- Comment #5 from Johnny Peyton --- Sorry for the delay. The fix for the KMP_USE_ADAPTIVE_LOCKS problem was committed. I don't know if another ticket was ever opened for the KMP_HAS_FUTEX problems, but I'm going to close this one since it was logically separate. -- 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 27145] New: IR for isfinite() could be improved?
https://llvm.org/bugs/show_bug.cgi?id=27145
Bug ID: 27145
Summary: IR for isfinite() could be improved?
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: spatel+l...@rotateright.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
#include
#include
bool foo(float x) { return isfinite(x); }
$ ./clang -O1 isnan.c -S -o - -emit-llvm
...
define zeroext i1 @foo(float %x) #0 {
entry:
%cmp.i = fcmp ord float %x, 0.00e+00
%0 = tail call float @llvm.fabs.f32(float %x) #2
%cmp1.i = fcmp une float %0, 0x7FF0
%1 = and i1 %cmp.i, %cmp1.i
ret i1 %1
}
Can't we use 'fcmp one' here to eliminate the first compare?
"one: ordered and not equal"
--
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 27129] Template alias crashes template diffing
https://llvm.org/bugs/show_bug.cgi?id=27129 rtr...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from rtr...@google.com --- Fixed in r264940 -- 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 26014] 'std::__1::underlying_type::type' from module 'xxx' is not present in definition of 'underlying_type<_Tp>' provided earlier
https://llvm.org/bugs/show_bug.cgi?id=26014 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Vassil Vassilev --- Fixed in r264937. -- 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 27146] New: LICM's AliasSetTracker is holding deleted values
https://llvm.org/bugs/show_bug.cgi?id=27146 Bug ID: 27146 Summary: LICM's AliasSetTracker is holding deleted values Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: lawre...@codeaurora.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 16134 --> https://llvm.org/bugs/attachment.cgi?id=16134&action=edit reduced testcase A problem similar to bug 3787. If I run loop reroll after LICM, I will hit the following Assert: An asserting value handle still pointed to this value! UNREACHABLE executed at /prj/llvm-arm/home/lawrence/llvmtrunk_latest/src/llvm/lib/IR/Value.cpp:744! #0 0x010f9548 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x10f9548) #1 0x010f7a56 llvm::sys::RunSignalHandlers() (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x10f7a56) #2 0x010f9d69 SignalHandler(int) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x10f9d69) #3 0x7f1b2e6decb0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xfcb0) #4 0x7f1b2da200d5 gsignal /build/eglibc-rrybNj/eglibc-2.15/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:64:0 #5 0x7f1b2da2383b abort /build/eglibc-rrybNj/eglibc-2.15/stdlib/abort.c:93:0 #6 0x010b147d llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x10b147d) #7 0x00d53e6c llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xd53e6c) #8 0x00d5371b llvm::Value::~Value() (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xd5371b) #9 0x00cfd739 llvm::CallInst::~CallInst() (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xcfd739) #10 0x00cfa076 llvm::Instruction::eraseFromParent() (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xcfa076) #11 0x00fb499d (anonymous namespace)::LoopReroll::runOnLoop(llvm::Loop*, llvm::LPPassManager&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xfb499d) #12 0x00957e9e llvm::LPPassManager::runOnFunction(llvm::Function&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x957e9e) #13 0x00d2409d llvm::FPPassManager::runOnFunction(llvm::Function&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xd2409d) #14 0x00d242eb llvm::FPPassManager::runOnModule(llvm::Module&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xd242eb) #15 0x00d24892 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0xd24892) #16 0x005b3f5b main (/prj/llvm-arm/home/lawrence/llvmtrunk_latest/build_release/llvm/bin/opt+0x5b3f5b) #17 0x7f1b2da0b76d __libc_start_main /build/eglibc-rrybNj/eglibc-2.15/csu/libc-start.c:258:0 The problem is that LICM is designed to do runOnLoop for all the loop first, then go to next opt, because it keep the AliasSetTracker around for outer loop, AliasSetTracker created the ValueHandle (type Assert), without destructing the AliasSetTracker, the ValueHandle will be kept around. Then if we run any other opt after LICM (before destructing AliasSetTracker), we will run into this kind of Assert. I am thinking either we have to destruct AliasSetTracker every time in LICM; Or we have to pass a flag to LICM to destruct AliasSetTracker if flag is set. Any thoughts or suggestion? Command to reproduce: bin/opt -licm -loop-reroll -debug-only=loop-reroll -S t.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 27147] New: Clang++ incorrectly treats T::T as T
https://llvm.org/bugs/show_bug.cgi?id=27147
Bug ID: 27147
Summary: Clang++ incorrectly treats T::T as T
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: ytj...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
Hi there,
I think clang++ incorrectly accept the following code,
#include
#include
int main() {
struct A {};
A::A::A::A::A::A::A::A a;
assert(typeid(a) == typeid(A));
}
both clang++, icc and GCC 4.4.7 accept this code. However GCC >= 4.5.3 rejects
this code. CMIIW, I don't think this is valid C++ code.
Here is compiling result from online compiler: https://godbolt.org/g/MLWej5
Regards,
Tianjiao
--
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 27148] New: Clang incorrectly treat capture-by-reference variable in lambda as constexpr
https://llvm.org/bugs/show_bug.cgi?id=27148
Bug ID: 27148
Summary: Clang incorrectly treat capture-by-reference variable
in lambda as constexpr
Product: clang
Version: 3.8
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: ytj...@gmail.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The following code shows clang has inconsistent behavior.
struct A {
constexpr operator int() const { return 0; }
};
int main() {
A a;
[&a]() { constexpr int b = a; }; // clang incorrectly accepted
A &ra = a;
constexpr int b = ra; // clang rejected
}
--
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 27149] New: llvm-config --obj-root and --prefix same output
https://llvm.org/bugs/show_bug.cgi?id=27149 Bug ID: 27149 Summary: llvm-config --obj-root and --prefix same output Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tabloid.adr...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified my build dir and install dir is different. Both dev tree and installed llvm-config return same result for these two options. -- 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 27122] Assertion `InitE && "No initialization expression?"' failed.
https://llvm.org/bugs/show_bug.cgi?id=27122 George Burgess changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from George Burgess --- Should be fixed by r264975. Thanks for the report :) -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27150] New: LTO linked llvm-tblgen crashes on startup
https://llvm.org/bugs/show_bug.cgi?id=27150 Bug ID: 27150 Summary: LTO linked llvm-tblgen crashes on startup Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Output: $ ./llvm-tblgen Could not open input file '': Bad address It seems that static constructors aren't properly called. I noticed the following difference between gold-plugin and lld: gold-plugin: $ readelf -SW ./llvm-tblgen |grep "init" [11] .init PROGBITS00402e00 002e00 1a 00 AX 0 0 4 [25] .init_array INIT_ARRAY 005a9990 1a8990 48 00 WA 0 0 8 $ readelf -SW ./llvm-tblgen |grep "ctors" # lld: $ readelf -SW ./llvm-tblgen |grep "init" [18] .init PROGBITS001e4f78 1d4f78 1a 00 AX 0 0 4 [24] .init_array INIT_ARRAY 001e6010 1d6010 08 00 WA 0 0 8 $ readelf -SW ./llvm-tblgen |grep "ctors" [25] .ctorsPROGBITS001e6018 1d6018 40 00 WA 0 0 8 Shouldn't we get only an .init_array of size 48 on lld as well? -- 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 27151] New: InstructionSimplify turns NaN to 0.0
https://llvm.org/bugs/show_bug.cgi?id=27151
Bug ID: 27151
Summary: InstructionSimplify turns NaN to 0.0
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dav...@cs.rutgers.edu
CC: llvm-bugs@lists.llvm.org,
santosh.nagaraka...@gmail.com
Classification: Unclassified
LLVM optimizes this code:
define float @foo(float %x) #0 {
entry:
%0 = fsub nnan ninf float 0.0, %x
%1 = fadd float %0, %x
ret float %1
}
to this:
define float @foo(float %x) #0 {
entry:
ret float 0.00e+00
}
My reading of the language reference is that the original program will return
NaN when %x is NaN (or +/-infinity). Specifically, the nnan flag on %0 means
that it will return an undefined value when %x is NaN, but it is required to
have defined behavior. That means %1 is calculated as normal, which means it
must return NaN, since %x is NaN.
>From the reference:
---
No NaNs - Allow optimizations to assume the arguments and result are not NaN.
Such optimizations are required to retain defined behavior over NaNs, but the
value of the result is undefined.
---
Counter argument: Since this is described in terms of optimizations instead of
instructions, it could be argued that the nnan in %0 is sufficient to allow the
optimization, even though %1 does not have nnan. This would mean adding nnan to
%0 affects every instruction that uses %x.
Here is the relevant code from InstructionSimplify.cpp:
// fadd [nnan ninf] X, (fsub [nnan ninf] 0, X) ==> 0
// where nnan and ninf have to occur at least once somewhere in this
// expression
Value *SubOp = nullptr;
if (match(Op1, m_FSub(m_AnyZero(), m_Specific(Op0
SubOp = Op1;
else if (match(Op0, m_FSub(m_AnyZero(), m_Specific(Op1
SubOp = Op0;
if (SubOp) {
Instruction *FSub = cast(SubOp);
if ((FMF.noNaNs() || FSub->hasNoNaNs()) &&
(FMF.noInfs() || FSub->hasNoInfs()))
return Constant::getNullValue(Op0->getType());
}
--
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 27152] New: cannot expand parameter pack of base classes outside the deriving class
https://llvm.org/bugs/show_bug.cgi?id=27152
Bug ID: 27152
Summary: cannot expand parameter pack of base classes outside
the deriving class
Product: clang
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: amidv...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
See example code that compiles with gcc-5.3 but not clang++ 3.7
==
#include
class Base1 {
public:
void foo() {
std::cout << "Base1" << std::endl;
}
};
class Base2 {
public:
void foo() {
std::cout << "Base2" << std::endl;
}
};
template
class Derived : public Bases... {
};
template
void call_foo_on_bases(Derived derived) {
using expander = int[];
(void) expander {0, (derived.Bases::foo(), 0)...};
}
int main() {
call_foo_on_bases(Derived());
}
==
The compile fails with this error using clang++ 3.7 -
main.cpp:31:50: error: pack expansion does not contain any unexpanded parameter
packs
(void) expander {0, (derived.Bases::foo(), 0)...};
Interestingly, if we change the above code to expand the pack of base classes
within the derived class, it compiles correctly (.e.g.)
// WORKS!
template
class Derived : public Bases... {
public:
void call_foo_on_bases() {
using expander = int[];
(void) expander {0, (Bases::foo(), 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 27153] New: InstCombine
https://llvm.org/bugs/show_bug.cgi?id=27153
Bug ID: 27153
Summary: InstCombine
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dav...@cs.rutgers.edu
CC: llvm-bugs@lists.llvm.org,
santosh.nagaraka...@gmail.com
Classification: Unclassified
LLVM optimizes this code:
define float @foo(i32 %x) #0 {
entry:
%y = and i32 %x, 268435455
%a = sitofp i32 %y to float
%b = fadd float %a, -8388608.0
ret float %b
}
to:
define float @foo(i32 %x) #0 {
entry:
%y = and i32 %x, 268435455
%addconv = add nsw i32 %y, -8388608
%b = sitofp i32 %addconv to float
ret float %b
}
This program calls foo and prints the result:
#include "stdio.h"
float foo(int x);
int main(int args, char** argv) {
float y = foo(33554434);
printf("%f\n",y);
return 0;
}
Without optimizations, this yields 25165824.00
With optimizations, this yields 25165826.00
This arises because 33554434 cannot be precisely represented as a float, so the
sitofp is constrained to return 33554432 or 33554436. This yields 25165824 or
25165828 when added to -8388608.
In the optimized code, the addition is performed in i32, yielding the exact
answer 25165826, which can be represented exactly as a float. Note that this is
different from both of the possible return values given above.
Here is the relevant code from InstCombineAddSub.cpp:
// Check for (fadd double (sitofp x), y), see if we can merge this into an
// integer add followed by a promotion.
if (SIToFPInst *LHSConv = dyn_cast(LHS)) {
// (fadd double (sitofp x), fpcst) --> (sitofp (add int x, intcst))
// ... if the constant fits in the integer value. This is useful for
things
// like (double)(x & 1234) + 4.0 -> (double)((X & 1234)+4) which no longer
// requires a constant pool load, and generally allows the add to be better
// instcombined.
if (ConstantFP *CFP = dyn_cast(RHS)) {
Constant *CI =
ConstantExpr::getFPToSI(CFP, LHSConv->getOperand(0)->getType());
if (LHSConv->hasOneUse() &&
ConstantExpr::getSIToFP(CI, I.getType()) == CFP &&
WillNotOverflowSignedAdd(LHSConv->getOperand(0), CI, I)) {
// Insert the new integer add.
Value *NewAdd = Builder->CreateNSWAdd(LHSConv->getOperand(0),
CI, "addconv");
return new SIToFPInst(NewAdd, I.getType());
}
}
--
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 27142] clang crashes on code with struct having fields of incomplete types
https://llvm.org/bugs/show_bug.cgi?id=27142 rtr...@google.com changed: 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27154] New: clang-3.8+ does not contain openmp headers and libs
https://llvm.org/bugs/show_bug.cgi?id=27154 Bug ID: 27154 Summary: clang-3.8+ does not contain openmp headers and libs Product: Packaging Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: deb packages Assignee: unassignedb...@nondot.org Reporter: pdk...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Unlike the pre-built binaries, the debian packages lack the openmp components, namely omp.h and libomp.so (and related symlinks). -- 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 27008] major vectorizer performance regression from 3.7.1
https://llvm.org/bugs/show_bug.cgi?id=27008 pdknsk changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from pdknsk --- This appears to be fixed now, if still somewhat slower, on par with pre-3.7 releases. clang version 3.9.0-svn264818-1~exp1 (trunk) Target: x86_64-unknown-linux-gnu $ clang-3.9 -march=haswell -O2 -std=c99 file.c -o file $ ./file 1048575999 0.409 $ clang-3.6 -march=haswell -O2 -std=c99 file.c -o file $ ./file 1048575999 0.410 -- 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 27137] wrong code at -O2 and -O3 in both 32-bit and 64-bit mode on x86_64-linux-gnu
https://llvm.org/bugs/show_bug.cgi?id=27137 Sanjoy Das changed: 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
