GMP and clang bugginess
nisse at lysator.liu.se
Mon May 25 11:57:43 UTC 2015
tg at gmplib.org (Torbjörn Granlund) writes:
> nisse at lysator.liu.se (Niels Möller) writes:
> I think that requiring an --enable-clang to be able to build with any
> version of clang on any platform whatsoever is a bit harsh.
> 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.
> On the other
> hand, a blacklisting of known broken compilers (by version and where
> relevant also by platform), and a --disable-compiler-blacklist option to
> override it, would be helpful to both users and us.
> This would be great, but it is a significant burden to maintain.
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 ;-)
> 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.
> Ideally, the blacklist in configure should automatically turn red
> entries to orange on the list of test results. And unexpected successes
> with a blacklisted compiler could also be marked in some happy color
> distinct from the usual green.
> The former is perhaps not so easy, the latter is simple.
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.
> Light green...?
Sounds good enough.
> 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.
> 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.
> How often do you yourself scan a manual for build problems before
> building a package? :-)
Before? Never. But if make or make check fails, I'll probably do a web
search on the package name and error message. And when all else fails,
I'd be tempted to refer to the fine documentation.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel