Help stabilising mini-gmp

[Torbjörn Granlund]

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

  tg at gmplib.org (Torbjörn Granlund) writes:
  
  > 2. The latest Gentoo doesn't support -fno-sanitize-recover.  I suppose
  >    it works without it?
  
  As I understand it, the point of -fno-sanitize-recover is to make
  programs crash on the spot when there's some undefined operation. Not
  sure what the behaviour is without that, if the program might complete
  normally with just logging of problems, or if detected problems still
  makes it exit with non-zero status.
  
Yes, it just prints some complaints.  This is not good for us, so now
ivydeb64v9 and ivydeb32v9 with newer compilers will run some tests with
these options.

So where are we now, wrt mini-gmp?

We're on more stable grounds, I think, now.  Less panic, more time for
other things.  But please let us finish this within some weeks.

Of the remaining https://gmplib.org/devel/mini-gmp-status.html issues I
worry most about #2.  Marco adjusted the parameters to make it faster,
but I remain unconvinced that g5.gmplib.org-dyn:32 really needed 400
seconds for the test with old parameters.  I suspect the code can hang
for certain seeds.  (We cannot tell the seed because of #1.)

I suspect we can just wait and see if it happens again (for the new,
smaller parameters).

#5 went away, I suspect the other t-str fixes solved it.

I am not sure #8 (alpha/dupont) is for real.

#15 is strange, I haven't tried to understand why these libgcc link
errors happens for just certain similar configs.

I am glad the "red" bugs had one cause (although a serious one).  It
would have been much worse with many errors of this kind.  (Well, the
results for end users are same same, but it matters for how to assess
code quality.)


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