https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #9 from Mark J Olah <molah at ucar dot edu> --- Thank you Karl and Jerry for the suggestions on transforming the code. It is not my own code, and I cannot modify it. It is however correct Fortran code, that currently builds fine with GCC 10.2.0, and all other Fortran compilers I have access to. I would like to be able to continue to compile this code with modern GCC-10.3.0+, but that is not practically possible without resolving this severe performance issue. I have read the explanation of the code generation, but this fails to explain why GCC is implementing an *exponential* algorithm to compute what should be a *linear complexity* operation. Moreover, testing shows the expense cannot be a result of MPFR. I can compute 32k acos() computations with MPFR to 53 bits of precision in about 3 sec. Also MPFR shows a perfectly linear scaling with N. Therefore the remaining ~1920 sec of compilation time representing 99.8% of the runtime must be spent doing something wasteful, and the exponential dependence on N is a result of a poor internal algorithm that is implemented by GCC. I would expect a compiler must do a reasonable job to compile correct Fortran code in a reasonable amount of time. The response for reporting significant algorithmic internal deficiencies of a compiler cannot be "change your code", otherwise the solution of your users will have to be "change the compiler".
