How clang is seen outside the community (Was: Re: [cfe-dev] david's integer overflow stuff)

Project Infrastructure LLVM Dev List Archives
#1

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:

/* 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. :slight_smile:

#2

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:

/* 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. :slight_smile:
P.P.S. Helps to send to correct list.

#3

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:

/* 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

#4

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

#5

This is more appropriate for cfe-dev, where you also posted this.

-Chris

#6

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:

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”…

#7

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.

#8

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

#9

The response from the person who is working on this: