Improving GMP configure

[Torbjorn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  As far as I understand, AC_PROG_CC doesn't do any backtracking, and
  gmp's current configure does something more advanced than (and different
  from) plain AC_PROG_CC.
  
  After rereading the docs for AC_PROG_CC, one possible approach might be
  to keep a list of potential compilers. First detect broken compilers and
  strike the from the list. Then invoke AC_PROG_CC with this list. Then
  the search AC_PROG_CC wouldn't really be used, but AC_PROG_CC would
  still do some useful work in figuring out options for ANSI-C and the
  like.
  
  As for backtracking, I don't know how that works or how it ought to
  work. To me it seems simpler to do *all* the checks that a compiler
  might fail before doing any other checks which depends on the selected
  compiler.
  
Does that really work?  Assume we have compiler A and B, with a
preference for compiler A.  The default ABI for A is 64-bit and the
default ABI for compiler B is 32-bit.  Furthermore, compiler A has a
nasty bug that affects just the 64-bit ABI, while its 32-bit ABI support
is awesome.  And to make things worse, B's support for the 32-bit ABI is
also affected by a nasty bug...

Now, how should GMP choose compiler and ABI under the new 'default'
feature?

This example might seem contrived, but I am afraid it is perfectly
realistic.  GCC 4.3.2 works in 32-bit mode, but any 64-bit backend is
badly broken.

-- 
Torbjörn