On 11/19/18 5:40 AM, Torbjörn Granlund wrote:
Richard Biener <rguent...@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
_______________________________________________
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
