BESSEL_JN Freezes for high-orders for quadruple reals

[Pavel_Holoborodko__A]

Hi, BESSEL_JN freezes for high-orders, e.g. BESSEL_JN(234,224.96Q0) never ends. I am using XE 2013 SP1 (w_fcompxe_2013_sp1.6.241). Could you please confirm if this bug is still present in newer versions of Intel Fortran Compiler? Thank you, Pavel.

[mecej4]

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.

[Kevin_D_Intel]

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)

[mecej4]

Kevin D:

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.

[Kevin_D_Intel]

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.

[Pavel_Holoborodko__A]

Kevin, could you please check whether this bug was fixed in 2017 update 4?

Thank you.

[mecej4]

I tried the example of #2 with the 32- and 64-bit versions of Ifort 17.0.4.210, and the problem remains.

[Pavel_Holoborodko__A]

Thank you! Will wait for next update.  

[Kevin_D_Intel]

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.

[Pavel_Holoborodko__A]

Kevin, thank you very much for confirmation. Any chance to know when update with the fix will be available?

[Kevin_D_Intel]

If they make the next 17.0 update the tentative target for that release is September.