Difference between revisions of "LLVM issues affecting LDC"

From D Wiki
Jump to: navigation, search
(LLVM 3.1)
m
 
(4 intermediate revisions by one other user not shown)
Line 1: Line 1:
This page lists issues in previous version of LLVM known to affect LDC.
+
This page lists issues in certain versions 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.
+
Because of such issues, use of the latest LLVM release is highly recommended in general. 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 ==
Line 17: Line 20:
 
</pre>
 
</pre>
 
: The issue does not occur on LLVM 3.0 and 3.2. Because of this, the release-mode std.exception unittests are executed [https://github.com/ldc-developers/ldc/commit/d33bfb0d42a117f0495f304921343a209a2441a4 with reduced optimizations] on x86_64 LLVM 3.1.
 
: The issue does not occur on LLVM 3.0 and 3.2. Because of this, the release-mode std.exception unittests are executed [https://github.com/ldc-developers/ldc/commit/d33bfb0d42a117f0495f304921343a209a2441a4 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):
 +
<pre>
 +
[…]
 +
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&)
 +
[…]
 +
</pre>
  
  
 
[[Category:LDC]]
 
[[Category:LDC]]
 +
[[Category:LLVM]]

Latest revision as of 11:22, 27 April 2014

This page lists issues in certain versions of LLVM known to affect LDC.

Because of such issues, use of the latest LLVM release is highly recommended in general. 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

[…]
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&) 
[…]