[Driver] Fix architecture triplets and search paths for Linux x32Currently, support for the x32 ABI is handled as a multilib to thex86_64 target only. However, full self-hosting x32 systems treati
[Driver] Fix architecture triplets and search paths for Linux x32Currently, support for the x32 ABI is handled as a multilib to thex86_64 target only. However, full self-hosting x32 systems treating itas a separate architecture with its own architecture triplets as well assearch paths exist as well, in Debian's x32 port and elsewhere.This adds the missing architecture triplets and search paths so thatclang can work as a native compiler on x32, and updates the tests sothat they pass when using an x32 libdir suffix.Additionally, we would previously also assume that objects from anyx86_64-linux-gnu GCC installation could be used to target x32. Thischanges the logic so that only GCC installations that include x32support are used when targetting x32, meaning x86_64-linux-gnux32 GCCinstallations, and x86_64-linux-gnu and i686-linux-gnu GCC installationsthat include x32 multilib support.Reviewed By: MaskRayDifferential Revision: https://reviews.llvm.org/D52050
show more ...
Enable generic multilib support on 32bit hosts. Previously this was onlyenabled for debian hosts, which is quite odd. I think all restriction onwhen Clang attempts to use a multilib installation sh
Enable generic multilib support on 32bit hosts. Previously this was onlyenabled for debian hosts, which is quite odd. I think all restriction onwhen Clang attempts to use a multilib installation should go away. Clangis fundamentally a cross compiler. It behaves more like GCC when builtas a cross compiler, and so it should just use multilib installs whenthey are present on the system. However, there is a very specificexemption for Exherbo, which I can't test on, so I'm leaving that inplace.With this, check in a generic test tree for multilib on a 32-bit host.This stubs out many directories that most distributions don't use butthat uptsream GCC supports. This is intended to be an agnostic test thatthe driver behaves properly compared with the GCC driver it aims forcompatibility with.Also, fix a bug in the driver that this testing exposed (see!) where itwas incorrectly testing the target architecture rather than the hostarchitecture.If anyone is having trouble with the tree-structure stubs I'm creatingto test this, let me know and I can revisit the design. I chose thisover (for example) a tar-ball in order to make tests run faster at thesmall, hopefully amortized VCS cost.llvm-svn: 140999