Funny clang behaviour
marc.glisse at inria.fr
Tue Feb 18 03:23:17 UTC 2020
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
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.
More information about the gmp-devel