GMP and clang bugginess

[Torbjörn Granlund]

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.

  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.

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?  I suggest
that this is the situation for x86.  Of course, we may define any
granularity here, with corresponding maintenance cost.

  If a user has the latest and greatest clang on a very vanilla x86 system
  where it actually works fine, the user is going to be pretty annoyed by
  an --enable-clang option, and possibly make it a habit to always use
  that option.
  
I suppose I need to make my point clearer by enabling broader clang
testing; I doubt there exist a clang release which does not miscompile
GMP for some -mtune= option...

  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.  Light
green...?
  
  It would also be useful to have an overview of known compiler issues
  somewhere on the web-page, and a pointer to that info in the
  bug-reporting chapter in the manual. A bit like the freebsd problems
  listed in recent NEWS.

I think this has limited value.  It will also tend to become a list of
obsolete issues, unless we remember to maintain it.  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".

How often do you yourself scan a manual for build problems before
building a package?  :-)
  
  >   BTW, it would be nice with an alternative test result page with
  >   problematic platforms only, or sorted with failing platforms at the top.
  >   
  > Not sure what you mean.  Just problematic confs, with the problematic
  > confs on top?  Or do you mean to put clang test results on a separate
  > page?
  
  Either some way to sort the current list so that builds with problems
  are at the top, followed by the all-green entries.
  
  Or a separate page, where the all-green entries are omitted.
  
  With the current list, quite a lot of scrolling is needed to identify
  the set of failed builds.
  
I'll see what I can do...

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