<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Apr 19, 2018 at 1:08 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 13:05:08 CEST Manuel Klimek wrote:<br>
> On Thu, Apr 19, 2018 at 12:55 PM Milian Wolff <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>> wrote:<br>
> > 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<br>
> > <br>
> > where<br>
> > <br>
> > > > you<br>
> > > > <br>
> > > > > > want to parse code that is dependent on a certain other compiler<br>
> > > > > > 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<br>
> > <br>
> > include<br>
> > <br>
> > > > > > paths<br>
> > > > > > and such.<br>
> > > > > <br>
> > > > > I'm not sure I understand what you mean - do you mean the compiler<br>
> > <br>
> > has<br>
> > <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>
> > <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>
> > <br>
> > $ clang -target arm-none-eabi -E -v - < /dev/null<br>
> > ..<br>
> > Target: arm-none--eabi<br>
> > ..<br>
> > <br>
> > #include <...> search starts here:<br>
> >  /usr/lib/clang/6.0.0/include<br>
> > <br>
> > ```<br>
> > <br>
> > So we still have to specify the include paths. But if we pass<br>
> > /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>
> <br>
> I'm not sure what's not working - can you show a code example that does not<br>
> work with clang -target arm-eabi?<br>
<br>
Please see the example based on the linaro toolchain I have given futher <br>
below.<br>
<br>
> > <snip><br>
> > <br>
> > > Again, there are multiple levels of builtin includes. If you want the<br>
> > <br>
> > right<br>
> > <br>
> > > ones for a target platform, you'll need to select that target platform -<br>
> > <br>
> > if<br>
> > <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<br>
> > also<br>
> > don't want the IDE user to configure clang manually to emulate a compiler.<br>
> > We<br>
> > want him to select a compiler (or find that automatically from the build<br>
> > system) and then configure clang for him.<br>
> <br>
> Unrelated but I think important for inclusiveness of the community: English<br>
> has singular they (<a href="https://en.wikipedia.org/wiki/Singular_they" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Singular_they</a>), which is a<br>
> nicely inclusive way to talk about indeterminate users :)<br>
<br>
TIL, thanks for the suggestion.<br>
<br>
> I do get that you don't want folks to need to configure clang to emulate a<br>
> compiler. Generally, clang tries to do that itself, and I'm told it's very<br>
> close to GCC and MSVC. For compilers that clang can emulate, the right way<br>
> is usually to translate flags to the other compiler into flags that clang<br>
> understands, like selecting the right target.<br>
> <br>
> That said, Clang will not be able to support all language extensions random<br>
> compilers have, which is why we're interested in real world example code to<br>
> better understand what wide spread differences there are.<br>
<br>
Right, I have given such an example below:<br></blockquote><div><br></div><div>Ah, sorry, I missed the neon part. So this works if we add -mcpu=cortex-a15. The problem is that the gcc cross compiler apparently has that configured at build time, and I'm not sure what the best way is to figure out the full settings for cpu / fpu and float-abi, but I think we'll need to find some way to gather them from the underlying cross compiler.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > One more example:<br>
> > <br>
> > ```<br>
> > $ wget<br>
> > <a href="https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux" rel="noreferrer" target="_blank">https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux</a><br>
> > -gnueabihf/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz<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>
> > <br>
> >  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih<br>
> >  f/<br>
> > <br>
> > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include<br>
> > <br>
> >  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih<br>
> >  f/<br>
> > <br>
> > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/include-fixed<br>
> > <br>
> >  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih<br>
> >  f/<br>
> > <br>
> > bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/<br>
> > include<br>
> > <br>
> >  /home/milian/Downloads/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabih<br>
> >  f/<br>
> > <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<br>
> > 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><br>
<br>
<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>