https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91858
--- Comment #10 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to rguent...@suse.de from comment #9) > It's likely by us doing > > mpfr_set_emin (-32990); > mpfr_set_emax (32766); > > during startup to work around a similar bug in MPC (IIRC it also > was tan ...). I suspect an internal overflow in the MPC computation, in which case doubling the precision at each iteration won't solve the issue. Setting emax to 14425 or below avoids the loop, but the real part of the result is slightly incorrect (0 instead of non-zero), though not affecting the binary32 exponent range, as this value is tiny: 1.0011111100101111e-28854 Changing the exponent range will solve the issue for some values, but I fear that whatever the exponent range is chosen, there may remain values that will trigger the bug. Paul Zimmermann says that this bug is fixed in the MPC development version.
