Bug in gmp/mpfr/mpc, never ending ctan computation
Dennis Clarke
dclarke at blastwave.org
Mon Nov 19 17:19:45 UTC 2018
On 11/19/18 5:40 AM, Torbjörn Granlund wrote:
> Richard Biener <rguenther at suse.de> writes:
>
> > __real x = 3.09126495087690770626068115234375e+8;
> > __imag x = -4.045689747817175388336181640625e+8;
> > volatile _Complex double y = ctan (x);
> > return 0;
> > }
> >
> > If we get a test case somewhat closer to GMP, then it is likely
> > somebody will look at it.
> >
> > I expect the maintainers of library called by gcc (mpc?) would be helped
> > by seeing the actual call to their library.
>
> OK, I can reproduce the issue with mpc 1.1.0, mpfr 3.1.4 and gmp 6.1.0
> using
>
> #include <mpc.h>
> #include <mpfr.h>
>
> int main()
> {
> mpc_t m;
> mpc_init2 (m, 53);
> mpfr_set_str (mpc_realref (m), "3.09126495087690770626068115234375e+8",
> 10, GMP_RNDN);
> mpfr_set_str (mpc_imagref (m), "-4.045689747817175388336181640625e+8",
> 10, GMP_RNDN);
> mpfr_clear_flags ();
> mpc_tan (m, m, 0);
> return 0;
> }
using that test I see 100% cpu and slowly growing RSS with a lot of time
being spent inside mpn_fft_fft and then mpn_fft_mul_2exp_modF :
Program received signal SIGINT, Interrupt.
0x00000008002dcd04 in __gmpn_copyi () from
/home/dclarke/local/lib/libgmp.so.10
(gdb) where
#0 0x00000008002dcd04 in __gmpn_copyi ()
from /home/dclarke/local/lib/libgmp.so.10
#1 0x000000080029a021 in mpn_fft_mul_2exp_modF (r=0x800e47610,
a=0x80150bcb0,
d=1600, n=40) at mul_fft.c:267
#2 0x000000080029a3f0 in mpn_fft_fft (Ap=0x800e8e130, K=32,
ll=0x800e00098,
omega=160, n=40, inc=16, tp=0x800e47610) at mul_fft.c:391
#3 0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc30, K=64,
ll=0x800e000a0,
omega=80, n=40, inc=8, tp=0x800e47610) at mul_fft.c:383
#4 0x000000080029a3b2 in mpn_fft_fft (Ap=0x800e8dc10, K=128,
ll=0x800e000a8,
omega=40, n=40, inc=4, tp=0x800e47610) at mul_fft.c:384
#5 0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=256,
ll=0x800e000b0,
omega=20, n=40, inc=2, tp=0x800e47610) at mul_fft.c:383
#6 0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=512,
ll=0x800e000b8,
omega=10, n=40, inc=1, tp=0x800e47610) at mul_fft.c:383
#7 0x00000008002995ff in mpn_mul_fft_internal (op=0x8014d4150, pl=9728,
k=9,
Ap=0x800e8dc10, Bp=0x800e8b410, A=0x8014fd610, B=0x801060950,
nprime=40,
l=19, Mp=5, fft_l=0x800e00070, T=0x800e47610, sqr=1) at mul_fft.c:738
#8 0x0000000800298ef8 in __gmpn_mul_fft (op=0x8014d4150, pl=9728,
n=0x801336980, nl=9475, m=0x801336980, ml=9475, k=9) at mul_fft.c:904
#9 0x00000008002cc6d6 in __gmpn_sqrmod_bnm1 (rp=0x8014a8500, rn=19456,
ap=0x801336980, an=9475, tp=0x8014d4150) at sqrmod_bnm1.c:194
#10 0x000000080029c568 in __gmpn_nussbaumer_mul (pp=0x8014a8500,
ap=0x801336980, an=9475, bp=0x801336980, bn=9475) at
nussbaumer_mul.c:61
--Type <RET> for more, q to quit, c to continue without paging--
#11 0x000000080029b80f in __gmpn_sqr (p=0x8014a8500, a=0x801336980, n=9475)
at sqr.c:97
#12 0x0000000800371726 in mpfr_sqrhigh_n (rp=0x801483500, np=0x801324180,
n=18947) at mulders.c:180
#13 0x000000080031c0ab in mpfr_mul (a=0x7fffffffde50, b=0x7fffffffde50,
c=0x7fffffffde50, rnd_mode=MPFR_RNDD) at mul.c:968
#14 0x000000080036b2c0 in mpfr_sqr (a=0x7fffffffde50, b=0x7fffffffde50,
rnd_mode=MPFR_RNDD) at sqr.c:561
#15 0x0000000800312bd0 in mpfr_exp_3 (y=0x7fffffffe350, x=0x7fffffffe380,
rnd_mode=MPFR_RNDD) at exp3.c:232
#16 0x000000080031487f in mpfr_exp (y=0x7fffffffe350, x=0x7fffffffe380,
rnd_mode=MPFR_RNDD) at exp.c:176
#17 0x000000080033a525 in mpfr_sinh_cosh (sh=0x7fffffffe550,
ch=0x7fffffffe530, xt=0x7fffffffe880, rnd_mode=MPFR_RNDN)
at sinh_cosh.c:108
#18 0x00000008003bf37b in mpc_sin_cos (rop_sin=0x7fffffffe7e0,
rop_cos=0x7fffffffe7a0, op=0x7fffffffe860, rnd_sin=17, rnd_cos=17)
at sin_cos.c:390
#19 0x00000008003c3756 in mpc_tan (rop=0x7fffffffe860, op=0x7fffffffe860,
rnd=0) at tan.c:196
#20 0x00000000002013c0 in main () at test_case.c:19
(gdb) quit
A debugging session is active.
Inferior 1 [process 58829] will be killed.
Quit anyway? (y or n) y
titan$
This is gmp 6.1.2 and mpfr-4.0.1-p13 and mpc-1.1.0 on FreeBSD 12.0RC1
and I also see similar behavior on Solaris SPARC.
>
> I simplified your test case using 1 as the real part and an integer for
> the imaginary part. With the real part set to 10000, the computation
> finishes in about 10 seconds, with every doubling of it the runtime
> almost triples. (If my observation generalises to an extended real part
> range, the compilation for your test case should terminate in about
> 10*3^log2(4.045689747817175388336181640625e+8/10000)/3600/24/365 years.)
>
Well the test case provided merely packs up and goes away with no
indication that it will return anytime soon.
I am just going to watch this thread closely.
Dennis
More information about the gmp-bugs
mailing list