[cfe-dev] Passing a triple to libclang

[Eli Bendersky]

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.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140604/9ecf2342/attachment.html>