RFC: Clang driver redesign (round 2)

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Clang driver redesign (round 2)

James Molloy-2
Hi,

Thanks for all the replies. I've kind of summarised the main points of
contest so far below and tried to group supporters and opponents. If
I've grouped you incorrectly, please don't take it slanderously :)

I've distilled the conversation so far into:
  * Accepted command line options should be easy to change, add and
    remove. Invoke time vs build time? Not decided.
  * Most options should be able to be modified at invoke time.

There have been discussions about invoke-time vs. build-time in terms of
specifying the driver behaviour - Can we discuss that a bit more?

Many people want to have a configuration file that can do almost
everything at invoke-time, but to cover all use cases that would
require turing completeness and a full-on scripting language, which
has been pooh-poohed already (and I don't agree with anyway).

My original suggestion was separating out "behavioural adaptation" and
"platform configuration" into different buckets.

"behavioural adaptation" could include the GCC compatibility story,
adding extra command line flags, exposing internal functionality etc.

"platform configuration" could include setting up a cross-toolchain,
multilib, include files, and even at a push changing the subtool to
invoke (for producing non-llvm output).

I'd suggest that behaviour changes should be done in C++ as it is
turing complete, fast, has precedent and these changes should in
general not differ between platforms or users.

Platform configuration can be done by a configuration file / spec
file, and because it is just setting parameters or options this can be
relatively simple, just variable assignment and string
manipulation/interpolation.

****

"To GCC or not to GCC, that is the question"
============================================

+Doug Gregor, Miles Bader
-Sean Hunt, Christopher Jefferson, Andrew Trick

There is differing opinion on the amount of GCC compatability clang
should offer. A lot of examples and arguments have been given, but I
see one conclusion - the driver should not be pinned to anything.

Depending on policy decisions, the user interface should be able to be
changed with minimal effort.

More command line options
=========================

+Matthew Monrocq, Ruben Van Boxem, Hal Finkel
-Eric Christopher

There were questions as to whether we should allow access to compiler
internal features or not. My personal opinion is that internal options
should be exposed both for power users and for remote debugging /
working around compiler errata before a patch is available.

Regardless, this ties in with the GCC question in that the option
should be there, should we choose to use it policy-wise.

Plugins producing non-llvm output
Driving extra optimizations
=================================

+David Chisnall

Excellent use cases that tie in well with what I have already. I'll
add them to the document.

Cross compile toolchain
=======================

+David Chisnall, Jean-Daniel Dupas

This is the exact same use case that we see here that is certainly not
covered by the current driver.




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

David Chisnall-2
On 8 Nov 2011, at 11:23, James Molloy wrote:

> "To GCC or not to GCC, that is the question"
> ============================================
>
> +Doug Gregor, Miles Bader
> -Sean Hunt, Christopher Jefferson, Andrew Trick
>
> There is differing opinion on the amount of GCC compatability clang
> should offer. A lot of examples and arguments have been given, but I
> see one conclusion - the driver should not be pinned to anything.
>
> Depending on policy decisions, the user interface should be able to be
> changed with minimal effort.

GCC compatibility is definitely an advantage, but if the driver infrastructure is tidied up then it becomes a lot easier to add new GCC-incompatible drivers as well.  I think a lot of people would like to see a cl.exe-compatible one that can just be dropped into MSVC, and it might also be useful to provide a driver that had a less human-friendly set of options that is easier for an IDE to invoke (e.g. no defaults, everything explicitly configured and driven by the IDE's build description).

One other use case I forgot to mention: Objective-C runtime selection.  This is easy on Darwin, because Apple ships an Objective-C runtime and supports it for the duration of that release.  It's much harder on other platforms, where the runtime is a third party package and may support some variable subset of the features that clang supports.  The driver currently sets a load of codegen flags based on the runtime on Darwin, and it would be great if we could have runtimes on other platforms just drop in a config file that clang would automatically pick up and use to describe them.  This would also make my life easier when I add new features to the GNUstep runtime, as I could just flip a switch in the config file and have clang use them, rather than having to rely on users adding yet more flags to their make files...

David

-- Sent from my Apple II
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

decalex
In reply to this post by James Molloy-2
On 08.11.2011 13:23, James Molloy wrote:
> Many people want to have a configuration file that can do almost
> everything at invoke-time, but to cover all use cases that would
> require turing completeness and a full-on scripting language, which
> has been pooh-poohed already (and I don't agree with anyway).

The two can be combined I think - configuration for let say 90% of the
cases + scripting language loaded as optional plugin for the rest.

Regarding configurations flexibility: Usually there are antagonism
between the two polar structures of configuration trees: a) Structure
symmetrical to full internal representations (fast and simple
validation/loading/storing), z) Short, human-friendly DSL (possibly with
inheritances, aliases, etc). In many projects the problem is resolved
using additional tool which translates z) to a) on demand (only on z
change), using a) templates as base.

Kind Regards,
Alek
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

David Chisnall-2
On 8 Nov 2011, at 12:10, Alek Paunov wrote:

> On 08.11.2011 13:23, James Molloy wrote:
>> Many people want to have a configuration file that can do almost
>> everything at invoke-time, but to cover all use cases that would
>> require turing completeness and a full-on scripting language, which
>> has been pooh-poohed already (and I don't agree with anyway).
>
> The two can be combined I think - configuration for let say 90% of the
> cases + scripting language loaded as optional plugin for the rest.
>
> Regarding configurations flexibility: Usually there are antagonism
> between the two polar structures of configuration trees: a) Structure
> symmetrical to full internal representations (fast and simple
> validation/loading/storing), z) Short, human-friendly DSL (possibly with
> inheritances, aliases, etc). In many projects the problem is resolved
> using additional tool which translates z) to a) on demand (only on z
> change), using a) templates as base.

I wondered if some of the tablegen infrastructure couldn't be reused for this, so we could have a configuration file format that could be compiled into C++ for the common cases, avoiding the need to parse it on every invocation.

David

-- Sent from my PDP-11
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Konstantin Tokarev
In reply to this post by decalex


08.11.2011, 16:10, "Alek Paunov" <[hidden email]>:

> On 08.11.2011 13:23, James Molloy wrote:
>
>>  Many people want to have a configuration file that can do almost
>>  everything at invoke-time, but to cover all use cases that would
>>  require turing completeness and a full-on scripting language, which
>>  has been pooh-poohed already (and I don't agree with anyway).
>
> The two can be combined I think - configuration for let say 90% of the
> cases + scripting language loaded as optional plugin for the rest.
>
> Regarding configurations flexibility: Usually there are antagonism
> between the two polar structures of configuration trees: a) Structure
> symmetrical to full internal representations (fast and simple
> validation/loading/storing), z) Short, human-friendly DSL (possibly with
> inheritances, aliases, etc). In many projects the problem is resolved
> using additional tool which translates z) to a) on demand (only on z
> change), using a) templates as base.

There's no need to separate "90%" from "the rest" and design new DSL.
You can just use Lua as configuration file format.

--
Regards,
Konstantin
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Matthieu Monrocq
In reply to this post by David Chisnall-2


Le 8 novembre 2011 13:08, David Chisnall <[hidden email]> a écrit :
On 8 Nov 2011, at 11:23, James Molloy wrote:

> "To GCC or not to GCC, that is the question"
> ============================================
>
> +Doug Gregor, Miles Bader
> -Sean Hunt, Christopher Jefferson, Andrew Trick
>
> There is differing opinion on the amount of GCC compatability clang
> should offer. A lot of examples and arguments have been given, but I
> see one conclusion - the driver should not be pinned to anything.
>
> Depending on policy decisions, the user interface should be able to be
> changed with minimal effort.

GCC compatibility is definitely an advantage, but if the driver infrastructure is tidied up then it becomes a lot easier to add new GCC-incompatible drivers as well.  I think a lot of people would like to see a cl.exe-compatible one that can just be dropped into MSVC, and it might also be useful to provide a driver that had a less human-friendly set of options that is easier for an IDE to invoke (e.g. no defaults, everything explicitly configured and driven by the IDE's build description).

One other use case I forgot to mention: Objective-C runtime selection.  This is easy on Darwin, because Apple ships an Objective-C runtime and supports it for the duration of that release.  It's much harder on other platforms, where the runtime is a third party package and may support some variable subset of the features that clang supports.  The driver currently sets a load of codegen flags based on the runtime on Darwin, and it would be great if we could have runtimes on other platforms just drop in a config file that clang would automatically pick up and use to describe them.  This would also make my life easier when I add new features to the GNUstep runtime, as I could just flip a switch in the config file and have clang use them, rather than having to rely on users adding yet more flags to their make files...

David

-- Sent from my Apple II


I fully support this idea!

I think we would all benefit from a tidier architecture where we could have:
> a clang driver: which gives us the opportunity to cleanly define option groups (whatever the policy, it can only be cleaner than gcc)
> a gcc compatible driver: in which we struggle to maintain the compatibility with gcc interface as much as possible
> possibly other special purpose drivers (MSVC is definitely one option, seeing as there is ongoing work to get MSVC compatible codegen and a Windows enabled libc++)

Note for compatibility drivers (gcc, MSVC): it's unnecessary to bring new options here, as the purpose is to provide a compatible interface (drop-in replacement) not an actual improved one. Also, if we have the translation going, we might as well generate a small tool that takes a "compatible" command-line and spits out the equivalent clang command line.

And this "multi-entry points" approach actually allow us to contend with the presence of a configuration file as well: want to use a configuration file ? Invoke the "configuration-file" driver.
(Although honestly, we could perfectly provide the configuration file thing as a variety of scripts parsing the file and generating the suitable command line)

If we have a clean Driver design, then adding several flavors of options parsing should be easy. Of course we would still need be reasonable and not spew dozens of them...

-- Matthieu

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Chris Lattner
In reply to this post by James Molloy-2
On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
> Thanks for all the replies. I've kind of summarised the main points of
> contest so far below and tried to group supporters and opponents. If
> I've grouped you incorrectly, please don't take it slanderously :)

Just MHO:

> "To GCC or not to GCC, that is the question"
> ============================================
>
> +Doug Gregor, Miles Bader
> -Sean Hunt, Christopher Jefferson, Andrew Trick
>
> There is differing opinion on the amount of GCC compatability clang
> should offer. A lot of examples and arguments have been given, but I
> see one conclusion - the driver should not be pinned to anything.

This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.

However, the challenge then becomes "why would anyone use the 'nice' one"?  It is likely to get less development and features, and users of the compiler don't care about academic purity of the implementation details.  Any features of the 'nice' driver would also need to supported by the 'ugly' driver also, so I don't see that introducing a new driver is really all that useful.

Features like better cross compiler support can be cleanly integrated into the current driver, so these seem like orthogonal goals.

> More command line options
> =========================
>
> +Matthew Monrocq, Ruben Van Boxem, Hal Finkel
> -Eric Christopher
>
> There were questions as to whether we should allow access to compiler
> internal features or not. My personal opinion is that internal options
> should be exposed both for power users and for remote debugging /
> working around compiler errata before a patch is available.

I tend to prefer very few command line options, but there is a practical limit.  I really don't like the GCC "tuning" options because:

 1) they are unstable (e.g. the units in the inlining thresholds)
 2) they get dropped into makefiles and forgotten / not reevaluated
 3) performance isn't stable across compiler changes / improvements.
 4) every new option is adds to the testing cross product, meaning that new flags are generally quite untested.

> Regardless, this ties in with the GCC question in that the option
> should be there, should we choose to use it policy-wise.

Clang specifically accepts and ignores a lot of GCC options.  This is a feature :).

> Plugins producing non-llvm output
> Driving extra optimizations
> =================================

+1 in the current driver.

> Cross compile toolchain
> =======================

+1 in the current driver.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Christopher Jefferson

On 8 Nov 2011, at 21:48, Chris Lattner wrote:

> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>> Thanks for all the replies. I've kind of summarised the main points of
>> contest so far below and tried to group supporters and opponents. If
>> I've grouped you incorrectly, please don't take it slanderously :)
>
> Just MHO:
>
>> "To GCC or not to GCC, that is the question"
>> ============================================
>>
>> +Doug Gregor, Miles Bader
>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>>
>> There is differing opinion on the amount of GCC compatability clang
>> should offer. A lot of examples and arguments have been given, but I
>> see one conclusion - the driver should not be pinned to anything.
>
> This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.
>
> However, the challenge then becomes "why would anyone use the 'nice' one"?

Ease of use.

I see stories like this over and over again when teaching students.

$ cat test.cc
#include <iostream>

int main(void)
{
  int i;
  std::cout << i;
}
$ clang test.cc
Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      ___cxx_global_var_init in t-vtk1TB.o
  "std::ios_base::Init::~Init()", referenced from:
      ___cxx_global_var_init in t-vtk1TB.o
  "std::cout", referenced from:
      _main in t-vtk1TB.o
  "std::ostream::operator<<(int)", referenced from:
      _main in t-vtk1TB.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
< wander off and ask someone why the code isn't compiling >
$ clang++ test.cc
$ ./a.out
1872097369
< wander off to ask why the code isn't working. Get told to enable warnings >
$ clang++ test.cc -Wall
t.cc:6:16: warning: variable 'i' is uninitialized when used here
      [-Wuninitialized]
  std::cout << i;
               ^
t.cc:5:8: note: initialize the variable 'i' to silence this warning
  int i;
       ^
        = 0
1 warning generated.
< grumbles, add the initialisation, code works>

I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.


Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

David Chisnall
On 9 Nov 2011, at 15:02, Christopher Jefferson wrote:

> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.

Give students an IDE, an example Makefile, or Cling?

David

-- Send from my Jacquard Loom
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Sean Hunt-2
On Wed, Nov 9, 2011 at 10:32, David Chisnall <[hidden email]> wrote:
> On 9 Nov 2011, at 15:02, Christopher Jefferson wrote:
>
>> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.
>
> Give students an IDE, an example Makefile, or Cling?
>
> David
>
> -- Send from my Jacquard Loom

You want to reduce the amount of magic you introduce students to at
once, and adding an IDE or build system is more magic.

Sean
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Chris Lattner
In reply to this post by Christopher Jefferson
Yes, I also think that is really annoying and should be fixed.  Why does fixing it require a new driver?

-Chris

On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <[hidden email]> wrote:

>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:
>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>>> Thanks for all the replies. I've kind of summarised the main points of
>>> contest so far below and tried to group supporters and opponents. If
>>> I've grouped you incorrectly, please don't take it slanderously :)
>>
>> Just MHO:
>>
>>> "To GCC or not to GCC, that is the question"
>>> ============================================
>>>
>>> +Doug Gregor, Miles Bader
>>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>>>
>>> There is differing opinion on the amount of GCC compatability clang
>>> should offer. A lot of examples and arguments have been given, but I
>>> see one conclusion - the driver should not be pinned to anything.
>>
>> This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.
>>
>> However, the challenge then becomes "why would anyone use the 'nice' one"?
>
> Ease of use.
>
> I see stories like this over and over again when teaching students.
>
> $ cat test.cc
> #include <iostream>
>
> int main(void)
> {
>  int i;
>  std::cout << i;
> }
> $ clang test.cc
> Undefined symbols for architecture x86_64:
>  "std::ios_base::Init::Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::ios_base::Init::~Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::cout", referenced from:
>      _main in t-vtk1TB.o
>  "std::ostream::operator<<(int)", referenced from:
>      _main in t-vtk1TB.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> < wander off and ask someone why the code isn't compiling >
> $ clang++ test.cc
> $ ./a.out
> 1872097369
> < wander off to ask why the code isn't working. Get told to enable warnings >
> $ clang++ test.cc -Wall
> t.cc:6:16: warning: variable 'i' is uninitialized when used here
>      [-Wuninitialized]
>  std::cout << i;
>               ^
> t.cc:5:8: note: initialize the variable 'i' to silence this warning
>  int i;
>       ^
>        = 0
> 1 warning generated.
> < grumbles, add the initialisation, code works>
>
> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.
>
>
> Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Ruben Van Boxem
2011/11/9 Chris Lattner <[hidden email]>
Yes, I also think that is really annoying and should be fixed.  Why does fixing it require a new driver?

-Chris

On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <[hidden email]> wrote:

>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:
>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>>> Thanks for all the replies. I've kind of summarised the main points of
>>> contest so far below and tried to group supporters and opponents. If
>>> I've grouped you incorrectly, please don't take it slanderously :)
>>
>> Just MHO:
>>
>>> "To GCC or not to GCC, that is the question"
>>> ============================================
>>>
>>> +Doug Gregor, Miles Bader
>>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>>>
>>> There is differing opinion on the amount of GCC compatability clang
>>> should offer. A lot of examples and arguments have been given, but I
>>> see one conclusion - the driver should not be pinned to anything.
>>
>> This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.
>>
>> However, the challenge then becomes "why would anyone use the 'nice' one"?
>
> Ease of use.
>
> I see stories like this over and over again when teaching students.
>
> $ cat test.cc
> #include <iostream>
>
> int main(void)
> {
>  int i;
>  std::cout << i;
> }
> $ clang test.cc
> Undefined symbols for architecture x86_64:
>  "std::ios_base::Init::Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::ios_base::Init::~Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::cout", referenced from:
>      _main in t-vtk1TB.o
>  "std::ostream::operator<<(int)", referenced from:
>      _main in t-vtk1TB.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> < wander off and ask someone why the code isn't compiling >
> $ clang++ test.cc
> $ ./a.out
> 1872097369
> < wander off to ask why the code isn't working. Get told to enable warnings >
> $ clang++ test.cc -Wall
> t.cc:6:16: warning: variable 'i' is uninitialized when used here
>      [-Wuninitialized]
>  std::cout << i;
>               ^
> t.cc:5:8: note: initialize the variable 'i' to silence this warning
>  int i;
>       ^
>        = 0
> 1 warning generated.
> < grumbles, add the initialisation, code works>
>
> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.
>
>
> Chris

Loosely related but not completely orthogonal; does LLVM provide an abstracted fool-proof API/Class to gather commandline arguments? Seeing that it provides a bunch of executables and lends itself to fronted development, I would think it should, something simple that reads all the arguments, converts them to some generic/specialized "commandlineoptions" structure, that the frontend can transparently use to get it's internal options from.

Or am I completely rambling?

Ruben


 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

reed kotler
Another requirement for the new driver should be "how are you going to test the damn thing"?
That should factor into the design.

I think some kind of simulation mode, i.e. like "make -n" or "make --just-print") should exist so that you can make test cases for this. Then you can capture expected output , etc.

Something more involved where you can provide answers to certain questions the driver will ask of the environment.

This is especially important considering the various platforms and targets.

On 11/11/2011 09:27 AM, Ruben Van Boxem wrote:
2011/11/9 Chris Lattner <[hidden email]>
Yes, I also think that is really annoying and should be fixed.  Why does fixing it require a new driver?

-Chris

On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <[hidden email]> wrote:

>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:
>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>>> Thanks for all the replies. I've kind of summarised the main points of
>>> contest so far below and tried to group supporters and opponents. If
>>> I've grouped you incorrectly, please don't take it slanderously :)
>>
>> Just MHO:
>>
>>> "To GCC or not to GCC, that is the question"
>>> ============================================
>>>
>>> +Doug Gregor, Miles Bader
>>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>>>
>>> There is differing opinion on the amount of GCC compatability clang
>>> should offer. A lot of examples and arguments have been given, but I
>>> see one conclusion - the driver should not be pinned to anything.
>>
>> This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.
>>
>> However, the challenge then becomes "why would anyone use the 'nice' one"?
>
> Ease of use.
>
> I see stories like this over and over again when teaching students.
>
> $ cat test.cc
> #include <iostream>
>
> int main(void)
> {
>  int i;
>  std::cout << i;
> }
> $ clang test.cc
> Undefined symbols for architecture x86_64:
>  "std::ios_base::Init::Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::ios_base::Init::~Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::cout", referenced from:
>      _main in t-vtk1TB.o
>  "std::ostream::operator<<(int)", referenced from:
>      _main in t-vtk1TB.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> < wander off and ask someone why the code isn't compiling >
> $ clang++ test.cc
> $ ./a.out
> 1872097369
> < wander off to ask why the code isn't working. Get told to enable warnings >
> $ clang++ test.cc -Wall
> t.cc:6:16: warning: variable 'i' is uninitialized when used here
>      [-Wuninitialized]
>  std::cout << i;
>               ^
> t.cc:5:8: note: initialize the variable 'i' to silence this warning
>  int i;
>       ^
>        = 0
> 1 warning generated.
> < grumbles, add the initialisation, code works>
>
> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.
>
>
> Chris

Loosely related but not completely orthogonal; does LLVM provide an abstracted fool-proof API/Class to gather commandline arguments? Seeing that it provides a bunch of executables and lends itself to fronted development, I would think it should, something simple that reads all the arguments, converts them to some generic/specialized "commandlineoptions" structure, that the frontend can transparently use to get it's internal options from.

Or am I completely rambling?

Ruben


 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________ cfe-dev mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Clang driver redesign (round 2)

Jean-Daniel Dupas-2

Le 11 nov. 2011 à 20:10, reed kotler a écrit :

Another requirement for the new driver should be "how are you going to test the damn thing"?
That should factor into the design.

I think some kind of simulation mode, i.e. like "make -n" or "make --just-print") should exist so that you can make test cases for this. Then you can capture expected output , etc.

Something more involved where you can provide answers to certain questions the driver will ask of the environment.

This is especially important considering the various platforms and targets.


Something like clang -### ?


On 11/11/2011 09:27 AM, Ruben Van Boxem wrote:
2011/11/9 Chris Lattner <[hidden email]>
Yes, I also think that is really annoying and should be fixed.  Why does fixing it require a new driver?

-Chris

On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <[hidden email]> wrote:

>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:
>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
>>> Thanks for all the replies. I've kind of summarised the main points of
>>> contest so far below and tried to group supporters and opponents. If
>>> I've grouped you incorrectly, please don't take it slanderously :)
>>
>> Just MHO:
>>
>>> "To GCC or not to GCC, that is the question"
>>> ============================================
>>>
>>> +Doug Gregor, Miles Bader
>>> -Sean Hunt, Christopher Jefferson, Andrew Trick
>>>
>>> There is differing opinion on the amount of GCC compatability clang
>>> should offer. A lot of examples and arguments have been given, but I
>>> see one conclusion - the driver should not be pinned to anything.
>>
>> This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.
>>
>> However, the challenge then becomes "why would anyone use the 'nice' one"?
>
> Ease of use.
>
> I see stories like this over and over again when teaching students.
>
> $ cat test.cc
> #include <iostream>
>
> int main(void)
> {
>  int i;
>  std::cout << i;
> }
> $ clang test.cc
> Undefined symbols for architecture x86_64:
>  "std::ios_base::Init::Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::ios_base::Init::~Init()", referenced from:
>      ___cxx_global_var_init in t-vtk1TB.o
>  "std::cout", referenced from:
>      _main in t-vtk1TB.o
>  "std::ostream::operator<<(int)", referenced from:
>      _main in t-vtk1TB.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> < wander off and ask someone why the code isn't compiling >
> $ clang++ test.cc
> $ ./a.out
> 1872097369
> < wander off to ask why the code isn't working. Get told to enable warnings >
> $ clang++ test.cc -Wall
> t.cc:6:16: warning: variable 'i' is uninitialized when used here
>      [-Wuninitialized]
>  std::cout << i;
>               ^
> t.cc:5:8: note: initialize the variable 'i' to silence this warning
>  int i;
>       ^
>        = 0
> 1 warning generated.
> < grumbles, add the initialisation, code works>
>
> I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.
>
>
> Chris

Loosely related but not completely orthogonal; does LLVM provide an abstracted fool-proof API/Class to gather commandline arguments? Seeing that it provides a bunch of executables and lends itself to fronted development, I would think it should, something simple that reads all the arguments, converts them to some generic/specialized "commandlineoptions" structure, that the frontend can transparently use to get it's internal options from.

Or am I completely rambling?

Ruben


 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________ cfe-dev mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- Jean-Daniel





_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev