GMP and clang bugginess

Torbjörn Granlund tg at
Mon May 25 12:24:12 UTC 2015

nisse at (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 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.
Make sense.

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
    make i-really-really-want-to-skip-testing
  to build the library without testing it.
I've played with that idea...

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list