LLVM only handles a hard-coded list of triples.

LLVM simply has a hard-coded list of triples for supported platforms in compiler/llvmGen/LlvmCodeGen/Ppr.hs :: moduleLayout.

Apparently this information can potentially be sourced by configure / autotools instead. This may be a better way forward rather than adding code for each platform.

changed weight to 5

added LLVM backend Tbug Trac import labels

Trac metadata

Trac field	Value
Version	7.6.1 → 7.7

mentioned in issue #7610

There are reports that setting up moduleLayout in compiler/llvmGen/LlvmCodeGen/Ppr.hs for a platform will make the right triple be selected, even in cross-compiling mode.

This may be sufficient, and I am testing it for my target platform now.

Trac metadata

Trac field	Value
Blocking	→ #7610

This bug is somewhat false. The .ll file generated by my x86_64-to-arm cross compiler starts with:

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32"
target triple = "arm-unknown-linux-gnueabi"

which is emitted by the code in LlvmCodeGen.Ppr.moduleLayout. If there's a bug here at all, it is that there are a fixed set of cases handled by moduleLayout, so to cross-compile for a new target you need to modify this code by hand.

I agree. Any fix for this should be in moduleLayout

changed title from Triple not passed to LLVM when cross-compiling to LLVM only handles a hard-coded list of triples.

changed the description

Yes, I've been meaning to update this bug. Doing now.

Trac metadata

Trac field	Value
Type	Bug → Task
TypeOfFailure	GhcDoesn'tWork → OtherFailure

changed milestone to %7.8.1

assigned to @trac-dterei

David, I've assigned this to you as you're our LLVM guru. Please unassign it if you don't plan to look at it.

changed milestone to %7.10.1

Moving to 7.10.1

unassigned @trac-dterei

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

mentioned in issue #10882 (closed)

closed

As far as I can tell this isn't a bug. As far as I know there is no way to avoid enumerating supported triplets like this. For instance, rustc has a very similar table.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

added cross-compilation + 1 deleted label

added Pnormal label