[PATCH] D54378: Add Hurd triplet

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 10 08:24:27 PST 2018


rengolin added a comment.

In https://reviews.llvm.org/D54378#1294254, @sthibaul wrote:

> Is that really supposed to work? I thought the rules was that the cpu parts and the vendor parts mustn't contain '-', and thus the splitting is never ambiguous, and the os part can contain '-' (heavily used by GNU/Linux, GNU/kFreeBSD, etc.)


That was my initial comment to Kristina. With triples, there is no must. It is what it is because it was so before. The reason you cannot add "hurd" to your triple is the same we cannot add extra dashes or reorder / insert, for public facing triples.

Internally, Clang normalises everything (sometimes destroying the meaning of the triple, because the previous meaning is "encoded" into the IR generated, and the IR triple is now for the back-end consumption).

So, there you have it, a triple is a bunch of things for different meanings and it gets completely decimated along its path through the compiler.

Getting even simple things right can go wrong in horrible ways. I believe that was Kristina original worry and I completely agree with her. It seems I was a bit more optimistic than I should today and Hurd made me smile.

Now, for the next steps, we'll have to go the hard way.

We'll need:

- complete tests, building Clang+LLVM, make check-all passing on at least one major arch
- Explanation of all variations a Hurd triple can take (additional flags, variants from other compilers)
- What does the OS/Env "gnu" means (does it mandate glibc, can it be used with some other libraries, etc)

And we'd also have to understand the actual conflict of the OS/Env "gnu" alternatives.


https://reviews.llvm.org/D54378





More information about the llvm-commits mailing list