'llvmc --clang' vs. 'ccc'

Hi,

I noticed that there is ongoing work [1] on extending ccc with
what looks like duplication of the functionality already present
in llvmc [2]. I just want to remind that llvmc's clang plugin was
recently rewritten [3] to make it usable as a drop-in replacement
for 'ccc'. The clang plugin is now compiled in by default, so you
can just alias 'ccc' to 'llvmc --clang' and use that instead of
the old 'ccc' script. Feedback is very much appreciated,
preferably in form of bug reports.

[1] http://article.gmane.org/gmane.comp.compilers.clang.scm/4177
[2] http://llvm.org/docs/CompilerDriver.html
[3] http://article.gmane.org/gmane.comp.compilers.llvm.devel/17087/

Hi Mikhail,

As you have noticed, I have been pursuing a non-llvmc based driver;
the end goal is to replace ccc with a fully C++ driver. I discussed
this several weeks ago with Anton and I presumed he relayed the jist
of our conversation to you.

I am planning on writing up some documentation on the approach and the
motivation today and sending it out, including the reasons for not
using llvmc. For now, the basic points are:

(1) My goals are a very high level of gcc compatibility and the
ability to be completely independent of the gcc driver (e.g., call cc1
directly). These goals seemed different and potentially at odds from
the emphasis of llvmc on extensibility.

(2) I don't agree that much of my current work is duplication of
functionality already present in llvmc. A significant part of my work
was trying to find an architecture which was "as clean as possible"
while allowing high gcc compatibility (including, for example,
integrating the Apple driver driver). I think most of my time has been
spent solving problems llvmc hasn't dealt with yet; for example, llvmc
uses LLVM's command line library to parse arguments, but this is
fundamentally different from how gcc handles arguments.

In the end, I hope that we converge to a single full featured driver,
but for the time being my goal was to get a highly functional driver
up and running as quickly as possible, and my judgement call was our
priorities are different enough that it made sense to implement a
separate tool.

- Daniel

Hi Daniel,

(2) I don't agree that much of my current work is duplication of
functionality already present in llvmc.

I didn't look into it closely, so I won't argue.

A significant part of my work
was trying to find an architecture which was "as clean as possible"
while allowing high gcc compatibility (including, for example,
integrating the Apple driver driver). I think most of my time has been
spent solving problems llvmc hasn't dealt with yet; for example, llvmc
uses LLVM's command line library to parse arguments, but this is
fundamentally different from how gcc handles arguments.

llvmc also strives to be a drop-in gcc replacement, and I think that
CommandLine is sufficient for that. What isn't possible to do with
CommandLine is cl.exe simulation; this is something we'll definitely
want to tackle at some point in the future. Support for fat binaries
is also on my TODO list.

[...] the
ability to be completely independent of the gcc driver (e.g., call cc1
directly).

This is certainly possible to do with llvmc, it was just easier to
reuse the gcc driver.

In the end, I hope that we converge to a single full featured driver,
but for the time being my goal was to get a highly functional driver
up and running as quickly as possible, and my judgement call was our
priorities are different enough that it made sense to implement a
separate tool.

OK, I see your point. If llvmc will benefit from your work, then it's
all for the better. I just think that llvmc's clang plugin needs more
feedback from its target audience, that's all.

There was an email from Chris which mentioned this I think. Currently, cocoa.m[m] tests are
broken, as are many of my private tests.

Trace looks like:

0 clang 0x00c02164 + 45
1 clang 0x00c0250f + 325
2 libSystem.B.dylib 0x945f3e4b _sigtramp + 43
3 libSystem.B.dylib 0xffffffff _sigtramp + 1805697503
4 clang 0x006b0b84 clang::TranslationUnit::~TranslationUnit() + 1258
5 clang 0x005bd47e clang::ParseAST(clang::Preprocessor&, clang::ASTConsumer*, bool, bool) + 804
6 clang 0x00068b9c + 1185
7 clang 0x0006adfd main + 2053
8 clang 0x0002717d start + 53

- Fariborz

Does this fix the issue for you?

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090112/010778.html

Yes it did.

- Thanks, Fariborz