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 
(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, 
     d=1600, n=40) at mul_fft.c:267
#2  0x000000080029a3f0 in mpn_fft_fft (Ap=0x800e8e130, K=32, 
     omega=160, n=40, inc=16, tp=0x800e47610) at mul_fft.c:391
#3  0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc30, K=64, 
     omega=80, n=40, inc=8, tp=0x800e47610) at mul_fft.c:383
#4  0x000000080029a3b2 in mpn_fft_fft (Ap=0x800e8dc10, K=128, 
     omega=40, n=40, inc=4, tp=0x800e47610) at mul_fft.c:384
#5  0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=256, 
     omega=20, n=40, inc=2, tp=0x800e47610) at mul_fft.c:383
#6  0x000000080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=512, 
     omega=10, n=40, inc=1, tp=0x800e47610) at mul_fft.c:383
#7  0x00000008002995ff in mpn_mul_fft_internal (op=0x8014d4150, pl=9728, 
     Ap=0x800e8dc10, Bp=0x800e8b410, A=0x8014fd610, B=0x801060950, 
     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 
--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

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.


More information about the gmp-bugs mailing list