Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

IEEE_SELECTED_REAL_KIND usage

IanH
Honored Contributor III
709 Views
I've been using IEEE_IS_NAN a lot, so I thought I'd get consistent with the kinds in the declarations of the associated REALs.

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.

0 Kudos
5 Replies
Steven_L_Intel1
Employee
709 Views

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.
0 Kudos
TimP
Honored Contributor III
709 Views

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?

0 Kudos
Steven_L_Intel1
Employee
709 Views

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.

0 Kudos
Steven_L_Intel1
Employee
709 Views

And here's the entry in the 14.0 installed manual:

isrk.png

0 Kudos
Steven_L_Intel1
Employee
709 Views

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.

0 Kudos
Reply