Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, 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;
>   }
> 
>   As I questioned in the first followup I wonder if GCC can tell mpc
>   to not exceed 53bits of precision for the result?  Even with denormals
>   a precision of 303084 bits isn't possible?
> 
> Use setrlimit(RLIMIT_CPU, ...) and a signal handler?  :-)

:/  But then with GCC we want deterministic behavior -- ISL
added some "computation budget" and error reporting if that was
taken up.  Maybe gmp/mpfr/mpc could consider adding such a thing
(reporting budget overruns via a signal could be acceptable if
the API churn would be too bad for another way).

> 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.)

Ick.  I wonder if the actual ctan result is infinite or we just
fail to compute it in an efficient manner...

Richard.

-- 
Richard Biener <rguenther at suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)