[cfe-commits] r89100 - /cfe/trunk/lib/Frontend/FrontendOptions.cpp

[Daniel Dunbar]

On Sun, Nov 22, 2009 at 11:52 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
> Hi,
>
> Ok, so here is what I get:
> vmware ~ # touch x.hpp
> vmware ~ # gcc -fsyntax-only x.hpp
> vmware ~ # g++ -fsyntax-only x.hpp
> vmware ~ # gcc --version
> gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4
> (...)
>
>
> Gcc 4.4 behaves the same way in fedora 12..
> You're right that clang doesn't still work, but at least this patch fixes
> clang-cc (I just verified now both things with a clean tree). In fact, this
> is one of the blockers of building inkscape.

Ok, I fixed this in r89630. My main point was that clang-cc is
irrelevant here, you didn't need to add it to clang-cc to fix the real
problem.

Unless you are one of those people trying to use clang-cc to actually
do things, which I am trying to wean people off of. :)

 - Daniel

> Nuno
>
>
> ----- Original Message -----
>>
>> Hi Nuno,
>>
>> On Tue, Nov 17, 2009 at 2:19 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
>>>
>>> The problem was that if you run 'clang/clang-cc -fsyntax-only file.hpp'
>>> the
>>> file was not being interpreted as a C++ file. gcc, on the other hand,
>>> does
>>> interpret .hpp files correctly as c++.
>>> I don't have the code here handy to be sure, but the problem I was facing
>>> was something along these lines (which was breaking the detection of
>>> boost
>>> by inkscape's configure).
>>
>> Yes, I understood that, the problem is that (a) your change doesn't
>> fix this, and (b) my gcc doesn't do this. Maybe this has changed in
>> upstream gcc, but (a) remains.
>> --
>> ddunbar at giles:tmp$ touch x.hpp
>> ddunbar at giles:tmp$ clang -fsyntax-only t.hpp
>> clang: warning: t.hpp: 'linker' input unused when '-fsyntax-only' is
>> present
>> ddunbar at giles:tmp$ gcc -fsyntax-only t.hpp
>> i686-apple-darwin10-gcc-4.2.1: t.hpp: linker input file unused because
>> linking not done
>> ddunbar at giles:tmp$
>> --
>>
>> - Daniel
>>
>>> Nuno
>>>
>>> ----- Original Message -----
>>> I don't buy it, I think something else is wrong. (My) gcc doesn't
>>> recognize .hpp as c++ either, and this change is to clang-cc not the
>>> driver, which always passes -x. So I don't get what this fixes?
>>>
>>> - Daniel
>>>
>>> On Tue, Nov 17, 2009 at 7:36 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
>>>>
>>>> Author: nlopes
>>>> Date: Tue Nov 17 09:36:35 2009
>>>> New Revision: 89100
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=89100&view=rev
>>>> Log:
>>>> recognize .hpp as c++ (needed for ./configure'ing boost)
>>>>
>>>> Modified:
>>>> cfe/trunk/lib/Frontend/FrontendOptions.cpp
>>>>
>>>> Modified: cfe/trunk/lib/Frontend/FrontendOptions.cpp
>>>> URL:
>>>>
>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendOptions.cpp?rev=89100&r1=89099&r2=89100&view=diff
>>>>
>>>>
>>>>
>>>> ==============================================================================
>>>> --- cfe/trunk/lib/Frontend/FrontendOptions.cpp (original)
>>>> +++ cfe/trunk/lib/Frontend/FrontendOptions.cpp Tue Nov 17 09:36:35 2009
>>>> @@ -25,7 +25,7 @@
>>>> .Case("mii", IK_PreprocessedObjCXX)
>>>> .Case("C", IK_CXX)
>>>> .Cases("C", "cc", "cp", IK_CXX)
>>>> - .Cases("cpp", "CPP", "c++", "cxx", IK_CXX)
>>>> + .Cases("cpp", "CPP", "c++", "cxx", "hpp", IK_CXX)
>>>> .Case("cl", IK_OpenCL)
>>>> .Default(IK_C);
>>>> }
>
>