Difference between revisions of "LLVM issues affecting LDC"
Klickverbot (talk | contribs) m (removed extra '=') |
Klickverbot (talk | contribs) (LLVM 3.3/OS X) |
||
Line 2: | Line 2: | ||
Because of such issues, use of the latest LLVM release is highly recommended. If there are no recent LLVM packages for your distribution, see [[Building LDC from source]]. LLVM is statically linked by default and can thus be removed again after building LDC. It does not have to be installed system-wide. | Because of such issues, use of the latest LLVM release is highly recommended. If there are no recent LLVM packages for your distribution, see [[Building LDC from source]]. LLVM is statically linked by default and can thus be removed again after building LDC. It does not have to be installed system-wide. | ||
+ | |||
+ | == LLVM 3.3 == | ||
+ | * TLS globals with weak linkage (as generated for static variables in D templates) [http://llvm.org/bugs/show_bug.cgi?id=15972 are completely broken in LLVM 3.3] ''on OS X'' (causing LDC to crash when e.g. building Phobos). Thus, please use LLVM 3.2 on OS X for the time being. | ||
== LLVM 3.1 == | == LLVM 3.1 == |
Revision as of 07:51, 28 August 2013
This page lists issues in previous version of LLVM known to affect LDC.
Because of such issues, use of the latest LLVM release is highly recommended. If there are no recent LLVM packages for your distribution, see Building LDC from source. LLVM is statically linked by default and can thus be removed again after building LDC. It does not have to be installed system-wide.
LLVM 3.3
- TLS globals with weak linkage (as generated for static variables in D templates) are completely broken in LLVM 3.3 on OS X (causing LDC to crash when e.g. building Phobos). Thus, please use LLVM 3.2 on OS X for the time being.
LLVM 3.1
- There is an infinite recursion bug in the scalar evolution optimization pass in LLVM 3.1 (LLVM PR: TBD). It is known to be triggered by the std.exception unit tests on x86_64. In GDB, the cycle looks similar to this:
[…] #2 llvm::ScalarEvolution::isKnownPredicate(llvm::CmpInst::Predicate, llvm::SCEV const*, llvm::SCEV const*) () #3 llvm::ScalarEvolution::getUMaxExpr(llvm::SmallVectorImpl<llvm::SCEV const*>&) () #4 llvm::ScalarEvolution::getUMaxExpr(llvm::SCEV const*, llvm::SCEV const*) () #5 llvm::ScalarEvolution::createSCEV(llvm::Value*) () #6 llvm::ScalarEvolution::getSCEV(llvm::Value*) () #7 llvm::ScalarEvolution::isImpliedCond(llvm::CmpInst::Predicate, llvm::SCEV const*, llvm::SCEV const*, llvm::Value*, bool) () #8 llvm::ScalarEvolution::isKnownPredicate(llvm::CmpInst::Predicate, llvm::SCEV const*, llvm::SCEV const*) () […]
- The issue does not occur on LLVM 3.0 and 3.2. Because of this, the release-mode std.exception unittests are executed with reduced optimizations on x86_64 LLVM 3.1.
LLVM 3.0
- There seems to be a bug in the MC code leading to crashes similar to this in rare cases (https://github.com/ldc-developers/ldc/issues/281):
[…] 3 ldc2 0x0000000000df9a6b llvm::MCAsmLayout::EnsureValid(llvm::MCFragment const*) const + 27 4 ldc2 0x0000000000dfa119 llvm::MCAsmLayout::getFragmentOffset(llvm::MCFragment const*) const + 9 5 ldc2 0x0000000000dfb23c llvm::MCAsmLayout::getSymbolOffset(llvm::MCSymbolData const*) const + 460 6 ldc2 0x0000000000dfb506 llvm::MCAssembler::EvaluateFixup(llvm::MCAsmLayout const&, llvm::MCFixup const&, llvm::MCFragment const*, llvm::MCValue&, unsigned long&) const + 310 7 ldc2 0x0000000000dfbb39 llvm::MCAssembler::HandleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 57 8 ldc2 0x0000000000dfeee3 llvm::MCAssembler::Finish() + 595 9 ldc2 0x00000000009781d5 llvm::AsmPrinter::doFinalization(llvm::Module&) […]