[Bug middle-end/96044] GCC hangs in tight loop resolving __builtin_jn using MPFR

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Jul 6 06:58:57 GMT 2020


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

More information about the Gcc-bugs mailing list