Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software Development Tools (Compilers, Debuggers, Profilers & Analyzers)
- Intel® Fortran Compiler
- IFORT define for infinity

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

Highlighted
##

bluequartz

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-24-2017
08:45 AM

68 Views

IFORT define for infinity

Is there a proper define for infinity? We get the following compilation errors under IFort v17 on Windows 10:

C:\Dashboards\EMsoft\EMsoftPublic\Source\EMsoftLib/constants.f90(103): error #7995: DEC$ ATTRIBUTES DLLIMPORT or DLLEXPORT data may not be equivalenced. [INFTY] REAL,public :: infty ---------------^ C:\Dashboards\EMsoft\EMsoftPublic\Source\EMsoftLib/constants.f90(108): error #7995: DEC$ ATTRIBUTES DLLIMPORT or DLLEXPORT data may not be equivalenced. [INFTYD] REAL(kind=dbl),public :: inftyd -------------------------^ compilation aborted for C:\Dashboards\EMsoft\EMsoftPublic\Source\EMsoftLib\constants.f90 (code 1)

This code compiles find under GFortran v6.2.

Thanks for any help.

4 Replies

Highlighted
##

Steve_Lionel

Black Belt Retired Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-24-2017
10:54 AM

68 Views

It seems the compiler is complaining about a !DEC$ ATTRIBUTES directive, not the declarations you show. You cut off the error message so we can't know what the problem is.

Please post a small but complete code sample, not just pieces of the error messages.

A standard-conforming way of obtaining an Infinity value is:

IEEE_VALUE (X,IEEE_POSITIVE_INF) ! or IEEE_NEGATIVE_INF

where X is a value or variable of the real kind you want an Infinity for and you have done a USE IEEE_ARITHMETIC to make the function available. This isn't allowed in a constant expression in Fortran 2008 - it will be in the next standard revision.

Highlighted
##

TimP

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-24-2017
10:55 AM

68 Views

I think we would need a complete working example of your problem, if you don't care to change the code.

I suppose that use of the Fortran HUGE() and ieee_arithmetic infinity constants would be recommended, as both gfortran and ifort have supported them for years now.

Highlighted
##

Here is the code snippet:
!----------------------------------------------------------------------------------------
! the rotations.f90 routines need to have access to the value +Infinity
! which is defined here (using the LaTeX name infty)
INTEGER,private :: inf
REAL,public :: infty
EQUIVALENCE (inf,infty) ! stores two variable at the same address
DATA inf/z'7f800000'/ !Hex for +Infinity
INTEGER(kind=8),private :: infd
REAL(kind=dbl),public :: inftyd
EQUIVALENCE (infd,inftyd) ! stores two variable at the same address
DATA infd/z'7FF0000000000000'/ !Hex for +Infinity
!----------------------------------------------------------------------------------------
! solution to Intel fortran compiler not liking the above definitions for infty and inftyd
!!REAL(kind=sgl),public :: infty = HUGE(0.0_sgl)
!!REAL(kind=dbl),public :: inftyd = HUGE(0.0_dbl)
!DEC$ ATTRIBUTES DLLEXPORT :: infty
!DEC$ ATTRIBUTES DLLEXPORT :: inftyd
!----------------------------------------------------------------------------------------
This is some of the explanation that I get from the author of the code:
*********
The comparison tests with the two definitions of infty do not give the same result, it seems; in the old definition, the value of infty is effectively the IEEE INF value, whereas using the HUGE() definition produces just a really large number, but not the IEEE INF. I'm not sure why the intel compiler did like these definitions; maybe we need to review that as well and see if there isn't a way to work with INF on intel...
*********
There are parts of the code that have calculations that result in infinity that we need to compare to actual Infinity. So we are trying to figure out how to rectify the 2 compilers behavior.
We will give
IEEE_VALUE (X,IEEE_POSITIVE_INF) ! or IEEE_NEGATIVE_INF
a try and see what happens.
After some more poking around on Google I see how to use it in a normal code line but is there a way to define a global constant?
I tried
INTEGER,private :: inf
REAL,public :: infty
!EQUIVALENCE (inf,infty) ! stores two variable at the same address
!DATA inf/z'7f800000'/ !Hex for +Infinity
infty = IEEE_VALUE (infty,IEEE_POSITIVE_INF)
and the compiler does like that, and it make sense because I am now defining something instead of just declaring it.

bluequartz

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-24-2017
11:28 AM

68 Views

Highlighted
##

Steve_Lionel

Black Belt Retired Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

10-24-2017
12:51 PM

68 Views

Ok - now you have posted enough for us to see the issue. The complaint is:

DEC$ ATTRIBUTES DLLIMPORT or DLLEXPORT data may not be equivalenced.

It has nothing to do with "defining infinity"

This is a restriction of the Intel compiler - what you are doing (DLLEXPORT) is nonstandard and compilers can apply their own rules to it.

You don't need to use EQUIVALENCE, though. The following works and is even standard (other than the DLLEXPORT):

module foo integer, parameter :: dbl = 8 REAL,public :: infty DATA infty/z'7f800000'/ !Hex for +Infinity REAL(kind=dbl),public :: inftyd DATA inftyd/z'7FF0000000000000'/ !Hex for +Infinity !DEC$ ATTRIBUTES DLLEXPORT :: infty !DEC$ ATTRIBUTES DLLEXPORT :: inftyd end

For more complete information about compiler optimizations, see our Optimization Notice.