On Mon, 17 Feb 2020, Torbjörn Granlund wrote:
Marc Glisse <marc.gli...@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
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
