<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, 2018 at 12:55 PM Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Donnerstag, 19. April 2018 12:25:00 CEST Manuel Klimek wrote:<br>
> On Wed, Apr 18, 2018 at 9:37 PM Milian Wolff <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>> wrote:<br>
> > On Mittwoch, 18. April 2018 12:25:40 CEST Manuel Klimek wrote:<br>
> > > On Tue, Apr 17, 2018 at 8:02 PM Milian Wolff via cfe-dev <<br>
> > > <br>
> > > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > > > Hey all,<br>
> > > > <br>
> > > > how does clangd or other users of the libclang handle situations where<br>
> > <br>
> > you<br>
> > <br>
> > > > want to parse code that is dependent on a certain other compiler or<br>
> > > > compiler<br>
> > > > environment? The most common scenario being embedded projects that<br>
> > <br>
> > rely on<br>
> > <br>
> > > > the<br>
> > > > compiler-builtin defines and include paths to find the sysroot include<br>
> > > > paths<br>
> > > > and such.<br>
> > > <br>
> > > I'm not sure I understand what you mean - do you mean the compiler has<br>
> > > builtins that clang doesn't provide and relies on their existence?<br>
> > <br>
> > Take this example code:<br>
> > <br>
> > ```<br>
> > #ifndef __arm__<br>
> > #error unsupported platform<br>
> > #endif<br>
> > <br>
> > #include <foobar.h><br>
> > <br>
> > static_assert(sizeof(void*) == 4);<br>
> > ```<br>
> > <br>
> > How can I parse this with libclang, such that it emulates my<br>
> > arm-none-eabi-<br>
> > gcc?<br>
> > <br>
> > <br>
> > - __arm__ should be defined, but not __x86_64__<br>
> > - foobar.h should be found in the default include paths for the<br>
> > arm-none-eabi-<br>
> > gcc compiler, not in the default include paths of libclang<br>
> > - it should be 32bit by default<br>
> <br>
> Using clang -target arm-eabi seems to do the trick?<br>
<br>
It doesn't for me:<br>
<br>
```<br>
$ arm-none-eabi-gcc -E -v - < /dev/null<br>
..<br>
Target: arm-none-eabi<br>
..<br>
#include <...> search starts here:<br>
 /usr/lib/gcc/arm-none-eabi/7.3.0/include<br>
 /usr/lib/gcc/arm-none-eabi/7.3.0/include-fixed<br>
 /usr/lib/gcc/arm-none-eabi/7.3.0/../../../../arm-none-eabi/include<br>
$ clang -target arm-none-eabi -E -v - < /dev/null<br>
..<br>
Target: arm-none--eabi<br>
..<br>
#include <...> search starts here:<br>
 /usr/lib/clang/6.0.0/include<br>
```<br>
<br>
So we still have to specify the include paths. But if we pass /usr/lib/gcc/<br>
arm-none-eabi/7.3.0/include as an include path, then clang will use the <br>
x86intrin.h from there, which it won't grog - it's highly GCC specific.<br></blockquote><div><br></div><div>I'm not sure what's not working - can you show a code example that does not work with clang -target arm-eabi?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<snip><br>
<br>
> Again, there are multiple levels of builtin includes. If you want the right<br>
> ones for a target platform, you'll need to select that target platform - if<br>
> that doesn't work with clangd, we need to fix it :)<br>
<br>
I don't think that setting the target on clang itself is sufficient. We also <br>
don't want the IDE user to configure clang manually to emulate a compiler. We <br>
want him to select a compiler (or find that automatically from the build <br>
system) and then configure clang for him.<br></blockquote><div><br></div><div>Unrelated but I think important for inclusiveness of the community: English has singular they (<a href="https://en.wikipedia.org/wiki/Singular_they">https://en.wikipedia.org/wiki/Singular_they</a>), which is a nicely inclusive way to talk about indeterminate users :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One more example:<br>
<br>
```<br>
$ wget <a href="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" rel="noreferrer" target="_blank">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</a><br>
<br>
$ unp gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz<br>
<br>
$ ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-<br>
gnueabihf-gcc -E -v - < /dev/null<br>
..<br>
Target: arm-linux-gnueabihf<br>
..<br>
 /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/<br>
bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include<br>
 /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/<br>
bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include-fixed<br>
 /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/<br>
bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/<br>
include<br>
 /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/<br>
bin/../arm-linux-gnueabihf/libc/usr/include<br>
..<br>
<br>
$ touch ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/../arm-<br>
linux-gnueabihf/libc/usr/include/please_find_this.h<br>
<br>
$ cat arm_test.cpp<br>
#ifndef __arm__<br>
#error unsupported platform<br>
#endif<br>
<br>
#include <arm_neon.h><br>
#include <please_find_this.h><br>
<br>
static_assert(sizeof(void*) == 4);<br>
<br>
int main() { return 0; }<br>
<br>
$ ./gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-<br>
gnueabihf-g++ arm_test.cpp<br>
<br>
$ clang++ -target arm-linux-gnueabihf arm_test.cpp<br>
#error "NEON support not enabled"<br>
..<br>
fatal error: too many errors emitted, stopping now [-ferror-limit=]<br>
20 errors generated.<br>
```<br>
<br>
So clearly, just specifying the target isn't enough. It's also a question of <br>
the other defaults for the compiler in question...<br>
-- <br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a><br>
<a href="http://milianw.de" rel="noreferrer" target="_blank">http://milianw.de</a></blockquote></div></div>