[cfe-dev] clangd/libclang: how to emulate other compilers?

Thu Apr 19 04:05:08 PDT 2018

On Thu, Apr 19, 2018 at 12:55 PM Milian Wolff <mail at milianw.de> wrote:

> On Donnerstag, 19. April 2018 12:25:00 CEST Manuel Klimek wrote:
> > On Wed, Apr 18, 2018 at 9:37 PM Milian Wolff <mail at milianw.de> wrote:
> > > On Mittwoch, 18. April 2018 12:25:40 CEST Manuel Klimek wrote:
> > > > On Tue, Apr 17, 2018 at 8:02 PM Milian Wolff via cfe-dev <
> > > >
> > > > cfe-dev at lists.llvm.org> wrote:
> > > > > Hey all,
> > > > >
> > > > > how does clangd or other users of the libclang handle situations
> where
> > >
> > > you
> > >
> > > > > want to parse code that is dependent on a certain other compiler or
> > > > > compiler
> > > > > environment? The most common scenario being embedded projects that
> > >
> > > rely on
> > >
> > > > > the
> > > > > compiler-builtin defines and include paths to find the sysroot
> include
> > > > > paths
> > > > > and such.
> > > >
> > > > I'm not sure I understand what you mean - do you mean the compiler
> has
> > > > builtins that clang doesn't provide and relies on their existence?
> > >
> > > Take this example code:
> > >
> > > ```
> > > #ifndef __arm__
> > > #error unsupported platform
> > > #endif
> > >
> > > #include <foobar.h>
> > >
> > > static_assert(sizeof(void*) == 4);
> > > ```
> > >
> > > How can I parse this with libclang, such that it emulates my
> > > arm-none-eabi-
> > > gcc?
> > >
> > >
> > > - __arm__ should be defined, but not __x86_64__
> > > - foobar.h should be found in the default include paths for the
> > > arm-none-eabi-
> > > gcc compiler, not in the default include paths of libclang
> > > - it should be 32bit by default
> >
> > Using clang -target arm-eabi seems to do the trick?
>
> It doesn't for me:
>
> ```
> $ arm-none-eabi-gcc -E -v - < /dev/null
> ..
> Target: arm-none-eabi
> ..
> #include <...> search starts here:
>  /usr/lib/gcc/arm-none-eabi/7.3.0/include
>  /usr/lib/gcc/arm-none-eabi/7.3.0/include-fixed
>  /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include
> $ clang -target arm-none-eabi -E -v - < /dev/null
> ..
> Target: arm-none--eabi
> ..
> #include <...> search starts here:
>  /usr/lib/clang/6.0.0/include
> ```
>
> So we still have to specify the include paths. But if we pass /usr/lib/gcc/
> arm-none-eabi/7.3.0/include as an include path, then clang will use the
> x86intrin.h from there, which it won't grog - it's highly GCC specific.
>

I'm not sure what's not working - can you show a code example that does not
work with clang -target arm-eabi?

> <snip>
>
> > Again, there are multiple levels of builtin includes. If you want the
> right
> > ones for a target platform, you'll need to select that target platform -
> if
> > that doesn't work with clangd, we need to fix it :)
>
> I don't think that setting the target on clang itself is sufficient. We
> also
> don't want the IDE user to configure clang manually to emulate a compiler.
> We
> want him to select a compiler (or find that automatically from the build
> system) and then configure clang for him.
>

Unrelated but I think important for inclusiveness of the community: English
has singular they (https://en.wikipedia.org/wiki/Singular_they), which is a
nicely inclusive way to talk about indeterminate users :)

I do get that you don't want folks to need to configure clang to emulate a
compiler. Generally, clang tries to do that itself, and I'm told it's very
close to GCC and MSVC. For compilers that clang can emulate, the right way
is usually to translate flags to the other compiler into flags that clang
understands, like selecting the right target.

That said, Clang will not be able to support all language extensions random
compilers have, which is why we're interested in real world example code to
better understand what wide spread differences there are.

> One more example:
>
> ```
> $ wget
> https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
>
> $ unp gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
>
> $ ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-
> gnueabihf-gcc -E -v - < /dev/null
> ..
> Target: arm-linux-gnueabihf
> ..
>
>  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/
> bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include
>
>  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/
> bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include-fixed
>
>  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/
> bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/
> include
>
>  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/
> bin/../arm-linux-gnueabihf/libc/usr/include
> ..
>
> $ touch ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/../arm-
> linux-gnueabihf/libc/usr/include/please_find_this.h
>
> $ cat arm_test.cpp
> #ifndef __arm__
> #error unsupported platform
> #endif
>
> #include <arm_neon.h>
> #include <please_find_this.h>
>
> static_assert(sizeof(void*) == 4);
>
> int main() { return 0; }
>
> $ ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-
> gnueabihf-g++ arm_test.cpp
>
> $ clang++ -target arm-linux-gnueabihf arm_test.cpp
> #error "NEON support not enabled"
> ..
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 20 errors generated.
> ```
>
> So clearly, just specifying the target isn't enough. It's also a question
> of
> the other defaults for the compiler in question...
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180419/806517ec/attachment.html>