<div class="gmail_quote">2011/11/9 Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yes, I also think that is really annoying and should be fixed.  Why does fixing it require a new driver?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Nov 9, 2011, at 7:02 AM, Christopher Jefferson <<a href="mailto:chris@bubblescope.net">chris@bubblescope.net</a>> wrote:<br>
<br>
><br>
> On 8 Nov 2011, at 21:48, Chris Lattner wrote:<br>
><br>
>> On Nov 8, 2011, at 3:23 AM, James Molloy wrote:<br>
>>> Thanks for all the replies. I've kind of summarised the main points of<br>
>>> contest so far below and tried to group supporters and opponents. If<br>
>>> I've grouped you incorrectly, please don't take it slanderously :)<br>
>><br>
>> Just MHO:<br>
>><br>
>>> "To GCC or not to GCC, that is the question"<br>
>>> ============================================<br>
>>><br>
>>> +Doug Gregor, Miles Bader<br>
>>> -Sean Hunt, Christopher Jefferson, Andrew Trick<br>
>>><br>
>>> There is differing opinion on the amount of GCC compatability clang<br>
>>> should offer. A lot of examples and arguments have been given, but I<br>
>>> see one conclusion - the driver should not be pinned to anything.<br>
>><br>
>> 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.<br>

>><br>
>> However, the challenge then becomes "why would anyone use the 'nice' one"?<br>
><br>
> Ease of use.<br>
><br>
> I see stories like this over and over again when teaching students.<br>
><br>
> $ cat test.cc<br>
> #include <iostream><br>
><br>
> int main(void)<br>
> {<br>
>  int i;<br>
>  std::cout << i;<br>
> }<br>
> $ clang test.cc<br>
> Undefined symbols for architecture x86_64:<br>
>  "std::ios_base::Init::Init()", referenced from:<br>
>      ___cxx_global_var_init in t-vtk1TB.o<br>
>  "std::ios_base::Init::~Init()", referenced from:<br>
>      ___cxx_global_var_init in t-vtk1TB.o<br>
>  "std::cout", referenced from:<br>
>      _main in t-vtk1TB.o<br>
>  "std::ostream::operator<<(int)", referenced from:<br>
>      _main in t-vtk1TB.o<br>
> ld: symbol(s) not found for architecture x86_64<br>
> clang: error: linker command failed with exit code 1 (use -v to see invocation)<br>
> < wander off and ask someone why the code isn't compiling ><br>
> $ clang++ test.cc<br>
> $ ./a.out<br>
> 1872097369<br>
> < wander off to ask why the code isn't working. Get told to enable warnings ><br>
> $ clang++ test.cc -Wall<br>
> t.cc:6:16: warning: variable 'i' is uninitialized when used here<br>
>      [-Wuninitialized]<br>
>  std::cout << i;<br>
>               ^<br>
> t.cc:5:8: note: initialize the variable 'i' to silence this warning<br>
>  int i;<br>
>       ^<br>
>        = 0<br>
> 1 warning generated.<br>
> < grumbles, add the initialisation, code works><br>
><br>
> 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.<br>
><br>
><br>
> Chris<br></div></div></blockquote><div><br>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.<br>
<br>Or am I completely rambling?<br><br>Ruben<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="HOEnZb"><div class="h5">

_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>