https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96044
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Paul Zimmermann from comment #7) > the problem is partly solved in MPFR development branch, where > jn(73333,73333) now takes about 2 seconds on my machine, and > jn(733333,733333) about 4 minutes. > Note that Wolfram Alpha fails for jn(73333,73333), and Pari/GP fails for > jn(733333,733333). Maybe a timeout should be put into the constant folding > code? The issue with timeouts (as in wall-clock) is that it makes builds dependent on CPU speed which is something we generally avoid. For ISL computations where we employ this kind of thing there's tracking of "number of ops" that are performed by ISL itself plus the ability for the client to set an upper bound after which operations return with an appropriate error. gmp/mpfr/mpc could for example track the number of 64bit multiplies and support limiting there - but I expect this would be a lot of work. Eventually we could make GCC use mini-gmp (would a host libmpfr then use the built-in mini-gmp?) and patch in this kind of accounting there... But IMHO simply classifying a value-range where we do and where we do not constant fold certain functions would be reasonable as well - unless C++ at some point magically requires to constexpr evaluate jn(). > With MPFR I get 4.9602731659759520e-03 whereas gcc -fno-builtin gives > 4.9602731659753978e-03, which is off by 639 ulps (assuming the MPFR value is > correct).
