Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

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

Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

OvermindDL1
On Fri, Sep 17, 2010 at 4:44 PM, David Chisnall <[hidden email]> wrote:
> On 17 Sep 2010, at 23:24, Chris Lattner wrote:
>> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them.
>
> Because the major negative comment that is raised when I suggest people adopt clang is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers.

This post from another newsgroup I frequent is somewhat related and
may give you any idea of a view of clang from outside the clang
community, but by people that are using it:

On Yesterday, someone somewhere else wrote:

> /* snip some */
> It's become clear to me in the past few days that while Clang excels
> in many areas, it is stunningly behind in one regard: the distributed
> driver implementation. Even in a GUI IDE, a programmer's experience
> with a compiler often revolves around the instantiation of a
> compilation through the composition of a cryptic string of flags.
>
> Clang, I'm afraid to say, takes the GCC approach in the worst way
> possible (I can understand that they haven't had time to document all
> command line options; heck, I'll even give them a pass on having whole
> groups of "hidden" options. But not even listing the --help-hidden
> command?). This is done in the name of compatibility with GCC, the
> existing compiler used in Xcode (the Mac development suite).
>
> This strange, archaic front-end implementation of Clang's otherwise
> brilliantly organized API will, IMHO, not only discourage its use and
> extend the longevity of the existing suite of overly complex make
> systems; it also directly inhibits our ability to implement plugins in
> Clang, because the clang++ driver does not provide any method for
> passing arguments to the underlying, collect2-style "clang++ -cc1"
> binary. Compiling hello world with a plugin (in addition to requiring
> the plugin to make a callback to the compilation process if it is just
> an inspector. The currently checked in version of the profiler doesn't
> do this, yet) ends up looking something like this:
>
> clang++ -cc1 -load ~/test/build/default/Profiler/libarielProfiler.so -
> plugin test-profiler -triple x86_64-unknown-linux-gnu -S -disable-
> free -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-
> elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-
> linker-version 2.20.51 -resource-dir /usr/local/lib/clang/2.9 -ferror-
> limit 19 -fmessage-length 179 -fexceptions -fgnu-runtime -fdiagnostics-
> show-option -fcolor-diagnostics -o foo.s -x c++ foo.cpp
>
> And that's just to get the assembly. You'd then have to invoke the
> linker on your own (and, as it's expected that the clang++ driver will
> be doing this, even the slightest mistake will break things).
> Alternatively, of course, we could modify the driver; but then, those
> looking to use any of the extensions we might create would have to use
> our modified driver.
>
> It gets better. Clang does not support DLL plugins (I think someone
> told me that Clang is not really working much on their plugin system
> ATM; they're trying to replace the GCC toolchain entirely on Darwin).
> In addition to the other Windows-related Clang problems /* snip */,
> the lack of DLL plugin support means that any
> further work on this Clang extensions would produce software that will
> be largely unfriendly to the native operating system of most of our
> target users (E.g. Boost community and C++ template metaprogramming
> community at large).

I am not sure which of these thoughts are accurate or not, but I have
heard similar things from others as well.  My experience with the
large amount of command parameters is similar to the above, but my
preferred C++ compiler would be one that compiles to a sqlite database
or something, and an entire 'project', source files and all (along
with probably the already tokanized code and other things) would all
be in such a single sqlite database, but ah, a dream...


P.S.  And yes, the broken mailserv headers here are also oddly *still*
different from the other 30+ mailing lists I frequent now.  :)
P.P.S.  Helps to send to correct list.

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

Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

Chris Lattner

On Sep 17, 2010, at 5:14 PM, OvermindDL1 wrote:

> On Fri, Sep 17, 2010 at 4:44 PM, David Chisnall <[hidden email]> wrote:
>> On 17 Sep 2010, at 23:24, Chris Lattner wrote:
>>> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them.
>>
>> Because the major negative comment that is raised when I suggest people adopt clang is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers.

this isn't an apple feature, afaik, noone at apple really uses -ftrapv because it is so broken in GCC.  The breakage and the bug reports were being filed by external people, e.g. the freebsd community.

> This post from another newsgroup I frequent is somewhat related and
> may give you any idea of a view of clang from outside the clang
> community, but by people that are using it:
>
> On Yesterday, someone somewhere else wrote:
>> /* snip some */
>> Clang, I'm afraid to say, takes the GCC approach in the worst way
>> possible

*shrug*  They are complaining that clang supports GCC compatible flags.  As you probably know, very little in clang is tied to this.  They are really just complaining that noone has gotten around to having a "clean and simple" command line interface to the compiler.  Besides noone stepping up to do this, it's unclear what purpose it would serve and what "clean and simple" really means.  All the complexity that exists is there for a reason.  If their GUI wrapper wants to be compatible with the worlds code, they will have to grapple with this complexity one way or the other.

-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: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

Douglas Gregor
In reply to this post by OvermindDL1

On Sep 17, 2010, at 5:14 PM, OvermindDL1 wrote:

> On Fri, Sep 17, 2010 at 4:44 PM, David Chisnall <[hidden email]> wrote:
>> On 17 Sep 2010, at 23:24, Chris Lattner wrote:
>>> I don't see how this affects adoption.  If they haven't adopted it yet, then a change from 2.7->2.8 won't affect them.
>>
>> Because the major negative comment that is raised when I suggest people adopt clang is that they don't want to be tied in to Apple's compiler.  It's much harder to convince them that clang is a community project that Apple is the largest contributor when the official policy is that issues that affect Apple code are show stoppers and patches that break Apple code are summarily reverted rather than having trivial fixes applied, while patches that break non-Apple code do not require any code review before committing (as long as Apple's stuff is fine) and are not considered release-blockers.
>
> This post from another newsgroup I frequent is somewhat related and
> may give you any idea of a view of clang from outside the clang
> community, but by people that are using it:
>
> On Yesterday, someone somewhere else wrote:
>> /* snip some */
>> It's become clear to me in the past few days that while Clang excels
>> in many areas, it is stunningly behind in one regard: the distributed
>> driver implementation. Even in a GUI IDE, a programmer's experience
>> with a compiler often revolves around the instantiation of a
>> compilation through the composition of a cryptic string of flags.
>>
>> Clang, I'm afraid to say, takes the GCC approach in the worst way
>> possible (I can understand that they haven't had time to document all
>> command line options; heck, I'll even give them a pass on having whole
>> groups of "hidden" options. But not even listing the --help-hidden
>> command?). This is done in the name of compatibility with GCC, the
>> existing compiler used in Xcode (the Mac development suite).
>>
>> This strange, archaic front-end implementation of Clang's otherwise
>> brilliantly organized API will, IMHO, not only discourage its use and
>> extend the longevity of the existing suite of overly complex make
>> systems; it also directly inhibits our ability to implement plugins in
>> Clang, because the clang++ driver does not provide any method for
>> passing arguments to the underlying, collect2-style "clang++ -cc1"
>> binary. Compiling hello world with a plugin (in addition to requiring
>> the plugin to make a callback to the compilation process if it is just
>> an inspector. The currently checked in version of the profiler doesn't
>> do this, yet) ends up looking something like this:
>>
>> clang++ -cc1 -load ~/test/build/default/Profiler/libarielProfiler.so -
>> plugin test-profiler -triple x86_64-unknown-linux-gnu -S -disable-
>> free -main-file-name foo.cpp -mrelocation-model static -mdisable-fp-
>> elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-
>> linker-version 2.20.51 -resource-dir /usr/local/lib/clang/2.9 -ferror-
>> limit 19 -fmessage-length 179 -fexceptions -fgnu-runtime -fdiagnostics-
>> show-option -fcolor-diagnostics -o foo.s -x c++ foo.cpp
>>
>> And that's just to get the assembly. You'd then have to invoke the
>> linker on your own (and, as it's expected that the clang++ driver will
>> be doing this, even the slightest mistake will break things).
>> Alternatively, of course, we could modify the driver; but then, those
>> looking to use any of the extensions we might create would have to use
>> our modified driver.
>>
>> It gets better. Clang does not support DLL plugins (I think someone
>> told me that Clang is not really working much on their plugin system
>> ATM; they're trying to replace the GCC toolchain entirely on Darwin).
>> In addition to the other Windows-related Clang problems /* snip */,
>> the lack of DLL plugin support means that any
>> further work on this Clang extensions would produce software that will
>> be largely unfriendly to the native operating system of most of our
>> target users (E.g. Boost community and C++ template metaprogramming
>> community at large).


I have no idea where this came from, but there are several ways to accomplish the task that the author alludes to (extending Clang to build their own tool) that are better than what s/he's describing:

        (1) Use Clang's Frontend library with their own driver or UI, so s/he has total control over the interface, whether it be different command-line arguments or something with checkboxes. Toggling bits in ClangInvocation would work perfectly fine.

        (2) Teach Clang's driver to pass -load and -plugin through to -cc1. A few minutes of coding eliminates the entire problem of having to think about -cc1. Users would just use something like

                clang++ -load ~/test/build/default/Profiler/libarielProfiler.so -plugin test-profiler foo.cpp

        (3) Extend Clang with a proper plug-in mechanism. The author isn't the only person interested in a plug-in system, but nobody has stepped up to really make it happen. Rather than complain that it's not being worked on, why not fix the core problem? I bet you'd even find some help along the way.


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

Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

Chandler Carruth
As I am also rather surprised by this perception, here is my perspective leading a team external to Apple doing exactly this -- building user-facing tools on top of Clang:

On Fri, Sep 17, 2010 at 5:49 PM, Douglas Gregor <[hidden email]> wrote:
I have no idea where this came from, but there are several ways to accomplish the task that the author alludes to (extending Clang to build their own tool) that are better than what s/he's describing:

       (1) Use Clang's Frontend library with their own driver or UI, so s/he has total control over the interface, whether it be different command-line arguments or something with checkboxes. Toggling bits in ClangInvocation would work perfectly fine.

Yep. We have tools that do this, many of them in fact. The APIs have rough edges, but they work well. We've had great success here.

Ironically, a large enabler for us was the ability to re-use the exact aspect of Clang that is being complained about -- GCC flag compatible parsing. Our tools work hard to co-exist with GCC flags and usages which are very prevalent, and being able to at a moments notice drop down and ask Clang to parse a set of GCC or Clang flags was incredibly useful.
 
       (2) Teach Clang's driver to pass -load and -plugin through to -cc1. A few minutes of coding eliminates the entire problem of having to think about -cc1. Users would just use something like

Doesn't "clang++ -Xclang -plugin -Xclang ..." work today? Maybe that's "too gross"...

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

Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

OvermindDL1
Helps if I send this to the mailing list since the mailing list does
not auto fill the headers like most others do annoyingly enough.

On Fri, Sep 17, 2010 at 8:11 PM, OvermindDL1 <[hidden email]> wrote:
> On Fri, Sep 17, 2010 at 7:09 PM, Chandler Carruth <[hidden email]> wrote:
>> Doesn't "clang++ -Xclang -plugin -Xclang ..." work today? Maybe that's "too
>> gross"...
>
> Nope, you need a -cc1 in there too, passing it to the driver does not
> pass the plugin down oddly enough, probably a simple fix though, may
> look later.
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

Douglas Gregor
-Xclang passes the next argument directly through to -cc1. You can use it to pass -cc1-specific arguments on the normal command line.

Sent from my iPhone

On Sep 17, 2010, at 7:11 PM, OvermindDL1 <[hidden email]> wrote:

> Helps if I send this to the mailing list since the mailing list does
> not auto fill the headers like most others do annoyingly enough.
>
> On Fri, Sep 17, 2010 at 8:11 PM, OvermindDL1 <[hidden email]> wrote:
>> On Fri, Sep 17, 2010 at 7:09 PM, Chandler Carruth <[hidden email]> wrote:
>>> Doesn't "clang++ -Xclang -plugin -Xclang ..." work today? Maybe that's "too
>>> gross"...
>>
>> Nope, you need a -cc1 in there too, passing it to the driver does not
>> pass the plugin down oddly enough, probably a simple fix though, may
>> look later.
>>
> _______________________________________________
> 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: Fwd: How clang is seen outside the community (Was: Re: david's integer overflow stuff)

OvermindDL1
The response from the person who is working on this:

On Sun, Sep 19, 2010 at 5:30 PM, wash wrote:
> Yah, -Xclang is broken, it passes options on to GCC for some reason. I've tried
> to from two different computers (at least it's broken in the plugin context).

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