[cfe-commits] r67863 - in /cfe/trunk: include/clang/Driver/Options.def tools/clang-cc/clang.cpp

[Mike Stump]

On Mar 27, 2009, at 1:54 PM, Chris Lattner wrote:
> Then why did you work against that plan by making clang-cc smarter?

My solution lies exactly on the path to that end.  If you test clang- 
cc, you'll discover it behaves exactly like gcc with regard to this  
option and that clang, when it is ready to suck up all of clang-cc,  
can just suck up these bits unmodified.  If you think there is an  
intermediate point that is easier to get to, and ends up with clang  
directly understanding the option, love to see it.  Take a typical  
command line:

clang -fno-common -fcommon -fno-common t.c  -###
clang version 1.0 (https://mrs@llvm.org/svn/llvm-project/cfe/trunk  
67865)
Target: x86_64-apple-darwin10
  "clang-cc" "-S" "-disable-free" "--relocation-model" "pic" "-- 
disable-fp-elim" "--unwind-tables=1" "--fmath-errno=0" "-mmacosx- 
version-min=10.6.0" "-fno-common" "-fcommon" "-fno-common" "-arch"  
"x86_64" "-o" "/tmp/cc-Tgm2pY.s" "-x" "c" "t.c"

here, notice that there is a minimum of translation happening in the  
driver, this is desirable, as it means that there is zero work to do  
post sucking up all of clang-cc into clang.

Essentially, a clang-cc that is smarter is exactly what clang will  
become, longer term.  One way to think of  clang-cc is a preflight  
area for clang.  Once clang does no translations, insertions or  
deletions, my claim it the last step of sucking up clang-cc is fairly  
trivial.

Now, all that said, maybe Daniel has a slightly different plan on  
exactly how best to accomplish this all.  I don't happen to recall  
seeing the detailed plan, though, maybe I missed it.

Anyway, regardless of all this, my primary point was to solve the  
problem the poster was having with compiling ruby, so as to encourage  
them to delve into the possible codegen issues.  That was the real  
point.