GMP and clang bugginess

[Niels Möller]

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

  make i-really-really-want-to-skip-testing

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.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.