- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But IEEE_SELECTED_REAL_KIND isn't playing nice for me under 11.1.046. I thought you could use it just like an analogue of SELECTED_REAL_KIND.
[plain]PROGRAM general_expr USE, INTRINSIC :: IEEE_ARITHMETIC, ONLY: IEEE_SELECTED_REAL_KIND IMPLICIT NONE WRITE (*, *) SELECTED_REAL_KIND(15) !WRITE (*, *) IEEE_SELECTED_REAL_KIND(15) ! error #8032 WRITE (*, *) IEEE_SELECTED_REAL_KIND(15, 200) END PROGRAM general_expr [/plain]If I uncomment the second WRITE I get an error about ambiguous references. The third line works, so onward and upward...
[cpp]PROGRAM init_expr USE, INTRINSIC :: IEEE_ARITHMETIC, ONLY: IEEE_SELECTED_REAL_KIND IMPLICIT NONE INTEGER, PARAMETER :: rk = SELECTED_REAL_KIND(15,200) !INTEGER, PARAMETER :: rk = IEEE_SELECTED_REAL_KIND(15,200) ! error #6259 REAL(rk) a_value a_value = 1.0_rk WRITE (*, *) a_value END PROGRAM init_expr [/cpp]When I swap the rk declaration statements I get an error about invalid stuff in constant expressions. Aw...
Advice appreciated.
Thanks,
IanH
PS: The online compiler help docs on the IEEE stuff refer to a IEEE_QUITE_NAN in a couple of places, which, quietly, is not quite right.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very interesting...
The initial problem is fallout from the way we have implemented the intrinsic modules. They're ordinary Fortran code and, in this case, IEEE_SELECTED_REAL_KIND is a generic with a bunch of specific routines for each possible combination of integer kind arguments, both optional. Unfortunately, this doesn't work when you just specify P as there are now four specifics that could match that. Hmm...
For the second, this is a glaring oversight on our part. The standard has wording to specifically allow IEEE_SELECTED_REAL_KIND in an initialization expression, and we missed that entirely. To fix this requires that we redesign the way we do intrinsic modules. Luckily, we ARE doing that, but it's not going to appear until the next major release. Sorry about that. This would also likely allow us to fix the first problem. Issue ID is DPD200141155.
I'll also let the writers know of the typo. Thanks for bringing this to our attention.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was looking up IEEE_selected_real_kind just now and this is the only reference I could find on Intel sites which didn't involve broken links. Nothing I could find in the installed compiler docs.
Was the solution to this issue to wipe out all subsequent references to it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim,
If you open the compiler documentation and search for IEEE_SELECTED_REAL_KIND, you get the entry. The current online link is here, but these links are not long-lived as they will break when the next version documentation is published. You can always start at the documentation index and go from there.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And here's the entry in the 14.0 installed manual:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahem. It's been a LOOOOOOONG time, but we are finally addressing both issues of our F2003 support in the next major release. It did take several iterations on a solution.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page