#14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: bgamari, kavon (added) Comment: Just for the record. The `*-hardfloat-*` vendor seems to be gentoo specific: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n1069. The `gen-data-layout.sh` script actually interrogates `clang`, to obtain the `data-layout`, cpu, and additional flags. Frankly the additional flags are still a bit fragile. I'm ok with adding: `armv7a-unknown-linux-gnueabi` to the list of llvm-targets. The case of `armv7a-hardfloat-linux-gnueabi`, which is not recognized as a proper llvm target, and llvm would only recognize as `armv7a-unknown-linux-gnueabihf`, I'm a bit reluctant to add, as it would result in a seemingly accepted target, while llvm would generate code for soft float, which seem unintentional. The customizable vendor flag though, I believe we should allow. I'm not perfectly sure if we should just strip it out in autoconf, and replace any vendor that's not part of the llvm-targets, with `unknown` as a fallback. E.g. `x86_64-UNREG-linux-gnu` would end up as `LLVM_TARGET=x86_64-unknown- linux-gnu`. I'm also more comfortable to make the `*-hardfloat-*-gnueabi` gentoo hack into a special casing in the configure script to have it end up as `LLVM_TARGET=...-unknown-...-gnueabihf`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14261#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler