- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin, could you please check whether this bug was fixed in 2017 update 4?
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried the example of #2 with the 32- and 64-bit versions of Ifort 17.0.4.210, and the problem remains.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you! Will wait for next update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin, thank you very much for confirmation. Any chance to know when update with the fix will be available?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If they make the next 17.0 update the tentative target for that release is September.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page