Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26748 Discussions

BESSEL_JN Freezes for high-orders for quadruple reals

Pavel_Holoborodko__A
207 Views
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.
0 Kudos
10 Replies
mecej4
Black Belt
207 Views

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
Employee
207 Views

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
Black Belt
207 Views

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
Employee
207 Views

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
207 Views

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

Thank you.

mecej4
Black Belt
207 Views

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
207 Views

Thank you! Will wait for next update.  

Kevin_D_Intel
Employee
207 Views

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
207 Views

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

Kevin_D_Intel
Employee
207 Views

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

Reply