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; } 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? :-) 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.) -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs