GMP and clang bugginess
tg at gmplib.org
Mon May 25 12:24:12 UTC 2015
nisse at lysator.liu.se (Niels Möller) writes:
> Harsh against whom? The point is not to make a statement, but to make
> it more likely that GMP works correctly for our users.
It's going to look very much like you're making a statement, whether or
not that's your intention.
Please don't let me be misunderstood, as already the The Animals said.
Assuming the blacklisting assumes that unknown newer versions are
working, it's sufficient to update it whenever a new broken compiler or
a new broken version gets widely used. And a general blacklisting of
clang will also need regular reconsideration.
I'd expect that there's going to be a clang version x in the not too
distant future which is able to compile gmp correctly at least on
x86_64. But I'm not going to place any bets on it ;-)
We could use a short clang whitelist instead of a clang blacklist? Here
is a beginning: "" :-)
> And, let's say that clang 3.4 works for compiling GMP on x86-64 except
> when passed -mtune=foo and -mtune=bar. Blacklisted or not?
Blacklist it if and only if those options are ever enabled automatically
by gmp's configure.
I am talking of such automatically enabled options (typically triggered
by config.guess' CPU name).
(I added some more clang testing on bdw.gmplib.org now, using clang 3.5
for many x86-64 CPUs.)
Assuming there's some blacklisting logic is in configure, and that our
test machines always configure using the blacklist-override option, one
could let the configure summary output a line saying that the
platform+compiler has known problems and is expected to fail. Then check
for that line when selecting the color.
I am grateful you engage in the automated GMP testing stuff. I really
need some offloading there. :-D
> I think this has limited value. It will also tend to become a list of
> obsolete issues, unless we remember to maintain it.
It needs to be updated whenever new issues worth documenting arrives.
There's no harm in historical data.
I disagree. The challenge is making people find the info and actually
read it. Descriptions of failing scenarios tend to be long, with subtle
pieces of information which determines the relevance.
> We need to keep in
> mind that of the users that compile GMP from source, very few will do
> anything but "configure; make; sudo make install".
Then maybe we chould have the default make target depend on check... So
those pesky users have to type
to build the library without testing it.
I've played with that idea...
Please encrypt, key id 0xC8601622
More information about the gmp-devel