GMP and clang bugginess

[Torbjörn Granlund]

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.
  
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...

-- 
Torbjörn
Please encrypt, key id 0xC8601622