Add support for the alternative arm*-hardfloat-* triples that are used
by Gentoo to the GCC installation detector, in order to make it possible
to link to gcc libraries while using the standard clang -target triples.
Add tests based on armhf Gentoo environment.
Details
Diff Detail
Event Timeline
It seems like we should teach Triple how to parse this triples correctly (i.e. to recognize that the vendor is ARM), and then canonicalize the environment to GNUEABIHF (or whatever)?
I've attempted that but altering the triple resulted in clang being unable to find gcc files (since the triple didn't match anymore). My previous patch is available here: https://595834.bugs.gentoo.org/attachment.cgi?id=450004. If you think that I've did something stupid-wrong there and there's a better way of doing this via Triple API, I'll gladly update the patch.
I think that you should update the triple class to return meaningful results and then also enhance Clang's search logic to find the GCC installation directory.
lib/Driver/ToolChains.cpp | ||
---|---|---|
1674 | You should test every new thing that you add. | |
test/Driver/linux-ld.c | ||
1016 | Right, I mean is this "4.9.3" there because the driver "found" it there, or is it generated by the compiler version you have on your machine, and that's why you created the directory with "4.9.3" in it? I'm worried that if it's the latter, the test will fail on any machine that doesn't have that compiler version. But I really don't know how it works, so it was an honest question. :) |
test/Driver/linux-ld.c | ||
---|---|---|
1016 | It's there because Driver founds it in Input directory structure. I don't have that version installed locally, if that's what worries you. You could say it's intentionally different from my install but I've simply copied the version used by other Gentoo tests. |
test/Driver/linux-ld.c | ||
---|---|---|
1016 | That answers my question, thanks! :) |
Please don't canonicalize the triple that way. The behavior of armv7-unknown-linux-gnueabi is different from armv7-unknown-linux-gnueabihf which is different from armv7-unknown-linux-gnueabihf -mfloat-abi=hard. I agree that this is absolutely terrible and unexpected, and a disaster from a user's perspective, but this is the world that we live in order to maintain compatibility with GCC.
How should I proceed, then? Was something along the lines of the earlier diff a better idea?
I think this patch should move to canonicalise the triple as per all the others, in the right place (vendor/environment).
If you find hardfloat or on where the vendor should be, and there are no other possible vendors, just append hf to the environment and mark the vendor as unknown. This works already with gnueabihf, eabihf and muslabihf (doubts about this last one).
What the clang driver accepts is different than what the rest of the compiler should use.
Ok but I think that then clang will not be able to find the gcc directory. Am I missing something obvious?
We already massage the triple in many cases, and what goes into IR is not always the same as what is used in Clang.
Examples are x86_64's "x32" extension to the ABI, ARM -> Thumb triples, adding compulsory dashes and unknowns (ex. x86_64--linux-gnu), etc.
You just have to find the right places.
I give up. I'm just going to complain to Gentoo ARM people a lot and maybe they'll fix their triples.
You're not testing this...