[cfe-dev] RFC: Clang driver redesign

[Christopher Jefferson]

On 4 Nov 2011, at 14:55, Sean Hunt wrote:

> On Fri, Nov 4, 2011 at 07:11, James Molloy <james.molloy at arm.com> wrote:
>> Usecase 3: Clang developer, developing
>> --------------------------------------
>> 
>> Wants no functionality to change - things keep working as normal [1]
>> 
>> Usecase 4: Apple/Darwin developer, using fat binaries
>> -----------------------------------------------------
>> 
>> Requires fat-binary support. This entails multiple "-arch" arguments
>> being supported. [1]
>> 
>> .. note::
>> 
>>    Describe this some more?
>> 
>> Functional requirements
>> =======================
>> 
>> The following requirements follow from the use cases above and attempt
>> to formalise those use cases more precisely.
>> 
>> [1] No functional regressions
>>  The driver **must** be able to be configured such that it can parse
>>  command lines that the current Clang driver accepts. The driver
>>  **must** invoke all subtools in the same manner as the current Clang
>>  driver, with the possible exception of obtuse, undefined, legacy or
>>  otherwise incorrect behaviour, permission for which must be obtained
>>  from the mailing list and documented in a subsection of this
>>  document for decision tracking.
> 
> I honestly have to disagree with this one. A lot of the reasons for
> horribleness in the current driver is compatibility with GCC. I
> believe that we should really have two drivers, one being the 'nice'
> driver, and one being the compatibility driver. To be honest, I
> consider POSIX specifications for CC rather irrigating as well, but
> I'm willing to concede POSIX compatibility. Naturally, it should be
> easy for these to both be changeable at once so that we don't have
> ridiculous levels of maintenance being performed, but I'm of opinion
> that the current model is predicated on enough levels of annoyances
> that trying to promote a compatible compiler is not a good approach
> (the first example that comes to mind is -Wall).

Having recently taught C++, I strongly agree. The two most obvious problems are:

a) Too low a default warning level

b) The 'clang' command's stupid treatment of C++ (inherited from gcc) where it will compile it, but not link in the standard library. I have to teach students that if they see the error message:

Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      ___cxx_global_var_init in z-pj7RVn.o
  "std::ios_base::Init::~Init()", referenced from:
      ___cxx_global_var_init in z-pj7RVn.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It means that tried compiling c++ with clang instead of clang++. Almost everyone hits it at some point, and it's impossible to diagnose without googling or help.

Chris