Hi,
the issue reported in September 2010 is still present:
https://gmplib.org/list-archives/gmp-devel/2010-September/001654.html
tarte% ./speed -s 1000,3000,1 -r mpn_sqrtrem mpn_rootrem.2
overhead 0.2 secs, precision 1 units of 3.53e-10 secs, CPU freq
2833.00 MHz
Zimmermann Paul paul.zimmerm...@inria.fr writes:
the issue reported in September 2010 is still present:
Such things happens sometimes. It means that we volunteers did not have
enough spare time for making the GMP gift better in that specific
respect.
Torbjörn
Please encrypt, key id
bodr...@mail.dm.unipi.it writes:
Maybe our printf/repl-vsnprintf.c is not tested enough?
Oddly enough it is not even listed at e.g.,
https://gmplib.org/devel/lcov/hannahnbsd32v61/gmp/printf/index.html.
Of the existing 21 function in printf/ only 17 are there. Great
coverage analysis! :-(
the issue reported in September 2010 is still present:
Such things happens sometimes. It means that we volunteers did not have
enough spare time for making the GMP gift better in that specific
respect.
there was no criticism in my mail (sorry if it seemed), I just wanted to
put this
Marc Glisse marc.gli...@inria.fr writes:
By the way, do we have a policy about breaking binary compatibility?
In this case, mixing old and new objects could result in crashes
(almost certainly at -O0, seldom at -O3). It should be possible to
prevent this issue by renaming __gmp_unary_expr
Ciao,
Il Mer, 22 Gennaio 2014 12:44 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Maybe our printf/repl-vsnprintf.c is not tested enough?
Oddly enough it is not even listed at e.g.,
https://gmplib.org/devel/lcov/hannahnbsd32v61/gmp/printf/index.html.
Well, it is
bodr...@mail.dm.unipi.it writes:
Well, it is wrapped with
#if ! HAVE_VSNPRINTF /* only need this file if we don't have vsnprintf */
[...]
#endif /* ! HAVE_VSNPRINTF */
so, on many systems it is not compiled at all... (and that's a reason why
it is less tested than other chunks
