Help stabilising mini-gmp
tg at gmplib.org
Mon Nov 21 16:02:28 UTC 2016
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
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,
#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
Please encrypt, key id 0xC8601622
More information about the gmp-devel