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

[Jonathan Roelofs via cfe-dev]

On 10/14/15 10:59 AM, C Bergström wrote:
>>
>>
>> I understand that's what you _want_ to do, but I still don't think that's
>> the _right_ thing to do.
>>
>> To name a specific example of undesirable effects of this series of patches,
>> consider someone filing a bug report: in order to diagnose what's going on,
>> now we'd need more than just the svn revision as printed in the version
>> string... we'd need to know how the particular build was configured, which
>> isn't something that the binary is able to tell us.
>
> There's lots of things which can impact the compiler beyond just the
> flags. I can add flags (optimizations) to gcc and build a version of
> clang which won't produce correct code. How would you diagnosis that?

Passing the testsuite, and LNT is a fairly good indication that you've 
got a working compiler.... that's what they're for.

> (Similar scenario?) What happens if some rare bug slips in and or some
> optimization is turned on and then that compiler builds a buggy libc++

libc++ has a testsuite, and passing that testsuite should give some 
confidence that both the library and the compiler used to build it are 
doing the right thing.

> (same?) I get what you're saying, but I don't think you can perfectly
> guard against compile time decisions by adding more flags.

That being said, both those examples are red herrings; hard-to-detect 
bugs in the bootstrap compiler aren't justification for making such 
design decisions in Clang, especially when a viable alternative has been 
proposed.

>
> I don't know why gcc does it, but gcc -v will give you the configure
> line which was used to build the compiler. Doing something similar
> when these options are enabled would give the information someone
> would need. I'm happy to add that change if it makes these patches
> palatable.

Renato gives a good explanation for why gcc was architected this way. 
Clang, on the other hand, was designed to be a universal driver. Not 
having these kinds of configuration flags baked in at compile time is 
part of Clang's design philosophy, and I've already explained why.

>
> Thanks for the tip on the test case.

You're welcome.

> If the other 3 patches get approval I'll add a test case for the 4th.

In case it wasn't clear, I'm actively objecting to the first three 
patches, and deferring the 4th for someone else to review.


Jon

>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded