[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

[C Bergström via cfe-dev]

On Thu, Oct 15, 2015 at 4:08 AM, Jonathan Roelofs
<jonathan at codesourcery.com> wrote:
>
>
> On 10/14/15 2:38 PM, cbergstrom at pathscale.com wrote:
>>
>> So let me make sure I understand everyone against my patch..
>>
>> #1 You are furiously against supporting clang which uses
>> compiler-rt, libc++ etc by default? Compiler-rt and the ability to
>> build a non-gnu toolchain by DEFAULT is such a worthless idea that it
>> has no value at all, right?
>
>
> No. We're not against having compiler-rt as the default. What we are
> against is _how_ these particular patches achieve that.
>

>
> To make that latter point more concrete, I'm suggesting that you rework your
> patches so that you use triples like: i686-pathscale-linux-gnu, and then you
> can set the default runtime lib based on the vendor part of that triple,
> i.e. 'pathscale'.

Small clarification - trying to get this upstream is entirely
altruistic. (PathScale as a product or company doesn't care or need
these upstream at all). I'm trying to do this because I see lots of
people having a difficult time testing OpenMP and other things from
time to time. Some of that work really depends on testing latest ToT
and having packages would make that a lot easier. I'd be really happy
if they were based off 100% open source and I'm not maintaining a
patchset on top of it.
-------------
To make sure I understand correctly
You want us to introduce something like this

x86_64-clang-linux-gnu
ppc64-clang-linux-gnu (This needs to be BE)
power8-clang-linux-gnu (This will be LE) # Also note I'd like the
default Scheduling Models between ppc64 (BGQ) and Power8 to be
different. This is yet another topic, but *may* be tied to the new
triples.
x86_64-clang-darwin (Sorry I don't know what the OSX triple should be)
aarch64-clang-linux
aarch64-clang-darwin (Not confirmed, but toying with the idea)
x86_64-clang-win
x86_64-clang-solaris
-----------
At compile time we would then set the default triple so the user
doesn't have to always include it, right?

I vaguely remember rather extensive problems when introducing a new
triple though. autoconf, cmake and other tools which do triple
detection may get messed up. Also x86_64-clang-linux-gnu vs gnu's
triple is effectively not different from a user or tools perspective.
It *should* just drop-in replace it and be compatible. Advertising it
as different doesn't really "feel" right.

While I'm happy to maintain the triples I introduce - I'm reluctant to
call it "pathscale" since it isn't an officially supported product.
(if *-clang-* collides with other triples I'm open to other
suggestions.. maybe *-notgnu-*)