Funny clang behaviour

[Marc Glisse]

On Mon, 17 Feb 2020, Torbjörn Granlund wrote:

> Marc Glisse <marc.glisse at inria.fr> writes:
>
>  It looks like there is now a standard header called <bit>. We also
>  have a test bit.c that compiles to bit. And we have a -I flag pointing
>  to the location of this second bit file. Now, when clang sees #include
>  <bit> inside the libc++ headers, it finds this binary file instead of
>  the standard header. I think we should fix that on the GMP side. The
>  easiest would be to rename the test from bit to something less common.
>
> What you say makes sense, but clang's behaviour does not.
>
> I added broad testing using C++ compilers for GMP now; there are 56
> variants.  Only clang 8 on FreeBSD fails.  All gcc versions (at least 6
> to 9) and older and newer clang worked fine.
>
> It is possible that it is timing-dependent; if a parallel compile
> generates ./bit late enough for other compiles to not see it, things
> will work.  But I don't see why all 4 clang8/fbsd compiles fail and all
> the other 52 compiles work.

I managed to reproduce on linux (debian) with CC='clang++-10 
-stdlib=libc++'.

For the failure to occur, you need to compile GMP with a C++ compiler (the 
error is in tests/mpz/ which would normally be C), the standard library 
has to be recent enough to have the header <bit>, and it needs to include 
<bit> from some other standard header.

Sure, the failure may appear or disappear depending on various factors, 
but in any case it seems like a good idea to avoid having a file with the 
same name as a standard header in a directory with a -I pointing to it.

-- 
Marc Glisse