[cfe-dev] Passing a triple to libclang

[Eric Christopher]

On Wed, Jun 4, 2014 at 2:25 PM, Eli Bendersky <eliben at google.com> wrote:
>
>
>
> On Wed, Jun 4, 2014 at 2:18 PM, Eric Christopher <echristo at gmail.com> wrote:
>>
>> On Wed, Jun 4, 2014 at 12:57 PM, Eli Bendersky <eliben at google.com> wrote:
>> > Hello,
>> >
>> > Currently libclang will refuse to parse code that contains
>> > target-specific
>> > builtin calls, and as far as I can tell it does not support passing in a
>> > triple (I get a "...libclang: crash detected during parsing").
>> >
>> > Has anyone else encountered this / filed a bug? It seems that
>> >
>> > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131104/092632.html
>> > is related but I didn't find any resolution from it.
>> >
>>
>> The original idea is that clang should be functional without needing
>> to link in the targets as its own library. However, given the asm
>> parsing desires for msvc I don't know that's completely valid anymore.
>> Tt could be possible to avoid doing the checking.
>>
>> That said, it might be worth splitting libclang into two parts - the
>> codegen/"need to parse assembly" part and the "I just want to parse
>> C/C++ source and skip over validation on assembly part". If we do that
>> split we could have a front end bit that's more useful for people
>> doing tooling and if you really want "gimme all of clang as a library"
>> we can have the "everything linked in" part. Effectively we'd be
>> making the larger library as a "gimme clang as a library without the
>> driver" which may be what people want.
>
>
> This is an interesting proposal, but I wonder if it will solve the specific
> problem I'm struggling with. Even to "just parse" the code, you need to be
> able to know about all builtins that are invoked. Some builtins in Clang,
> however, come from the backend via the GCCBuiltin construct in .td files;
> these are exposed to Clang, which then knows to recognize these builtins.
> Without having a target linked in, these builtins are no longer recognized
> and parsing fails, even on "pure C/C++/CUDA" without any inline assembly.
>

Yeah, I think that we'll need a different scheme for that - perhaps
similar to the neon ones or something else.

-eric