Yes, this bug is resent in 17.0.2. Also, with a program such as
program jnq real*16 x x=224.96q0 print *,BESSEL_JN(234,x) end program
compiling with /Od builds a program that hangs when it is run, and compiling without /Od (which uses the default /fast) the compiler attempts to evaluate the function value at compile time, causing the compiler itself to hang up.
Thank you Pavel and mecej4. I reproduced both issues and submitted (separately) to Development.
(Internal tracking id: DPD200419395 – run-time hang at /Od for BESSEL_JN with high-orders for quadruple reals)
(Internal tracking id: DPD200419396 – compile-time hang at default opt-level for BESSEL_JN with high-orders for quadruple reals)
I think that the two issues are really one and the same.
With optimizations enabled, the compiler probably evaluates (or attempts to, in this case) a constant expression at compile time. You can see this by changing REAL*16 to REAL*8, compiling the file and running DUMPBIN on the OBJ file. With /Od, you will see a call to __jn. With /O2, you will see a double precision value being loaded as an argument to for_write_seq_lis() -- the call to __jn has been made in the compiler itself.
Perhaps. I'm just uncertain whether they will share the same resolution/fix and come from the same development team. Development will/can close one as a duplicate as warranted. I submitted them with references to one another. Right now they are assigned to different Development teams. I appreciate your additional analysis.
Neither are fixed in Update 4. Development will try fixing CMPLRS-41749 (formerly DPD200419395) in the next 17.0 update later this year. For CMPLRS-42191 (formerly DPD200419396), Development confirmed the compiler hang results from calling the same routine causing the run-time hang; therefore, fixing the routine will also resolve the compilation issue.