Funny clang behaviour
tg at gmplib.org
Mon Feb 17 22:14:20 UTC 2020
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.
Please encrypt, key id 0xC8601622
More information about the gmp-devel