SETCONTROLFPQQ( ) causes exception in 64-bit compiler

[ocean]

Steve:

The following code appears to work fine in IVF 10.0, 32-bit, but it fails with an exception in the 64-bit version of the compiler:


use DFLIB

integer(2) control
call GETCONTROLFPQQ(control)
control = and (control, not (FPCW$INVALID) !throw exception for invalid numbers
control = and (control, not (FPCW$ZERODIVIDE) !throw exception for divide by zero
call SETCONTROLFPQQ(control)


Do you know of any issue associated with the function SETCONTROLFPQQ in IVF 10.0, 64-bit?

I'm using VS2005, running on Windows XP (64-bit). My application has been properly configured to run as a 64-bit process.

Thanks

[Steven_L_Intel1]

If I read the manual correctly, SETCONTROLFPQQ is supported for IA-32 only. I know it doesn't say this on the page for SETCONTROLFPQQ itself but it does on the "Using Exception, Precision, and Rounding Parameters Using Exception, Precision, and Rounding Parameters" page which is linked to by the SETCONTROLFPQQ page.

May I suggest instead the IEEE FP intrinsic modules from Fortran 2003?

[ocean]

Quoting - Steve Lionel (Intel)

If I read the manual correctly, SETCONTROLFPQQ is supported for IA-32 only. I know it doesn't say this on the page for SETCONTROLFPQQ itself but it does on the "Using Exception, Precision, and Rounding Parameters Using Exception, Precision, and Rounding Parameters" page which is linked to by the SETCONTROLFPQQ page.

May I suggest instead the IEEE FP intrinsic modules from Fortran 2003?

Steve,

Thanks for taking a look into this. I'm not very familiar with the IEEE FP intrinsic modules. I'll need to do some reading.You don't happen to have a source code sample that might help setting up exceptions for invalid numbers and division by zero, just like we did with the SETCONTROLFPQQ function?

Thanks

[ocean]

Quoting - ocean

Steve,

Thanks for taking a look into this. I'm not very familiar with the IEEE FP intrinsic modules. I'll need to do some reading.You don't happen to have a source code sample that might help setting up exceptions for invalid numbers and division by zero, just like we did with the SETCONTROLFPQQ function?

Thanks

The IVF documentation has an example that might work for me.

Thanks

[g_f_thomas]

Quoting - Steve Lionel (Intel)

If I read the manual correctly, SETCONTROLFPQQ is supported for IA-32 only. I know it doesn't say this on the page for SETCONTROLFPQQ itself but it does on the "Using Exception, Precision, and Rounding Parameters Using Exception, Precision, and Rounding Parameters" page which is linked to by the SETCONTROLFPQQ page.

May I suggest instead the IEEE FP intrinsic modules from Fortran 2003?

Is there a way to get the new IEEE FP stuff to check if the processor supports all that one assumes of it? For instance how can it check on the validity of input arguments to the Fortran intrinsics, eg sqrt(-2)? I'm just familiarizing myself with this new f2003 feature of ivf 11.

Thanks
Gerry

[Steven_L_Intel1]

I'm not completely sure what you're asking.

Module IEEE_EXCEPTIONS and IEEE_ARITHMETIC have inquiry functions such as IEEE_SUPPORT_FLAG and IEEE_SUPPORT_NAN to ask about the FP environment to see if certain features are supported.

For a situation such as SQRT(-3), this can be detected by asking if the exception IEEE_INVALID occurred. Here's an example.

[plain]program ieee_test
use, intrinsic :: IEEE_ARITHMETIC
use, intrinsic :: IEEE_FEATURES
implicit none

real x, y
type(IEEE_STATUS_TYPE) STATUS_VALUE
logical flag

do
write (*,'(A)',ADVANCE="NO") "Enter value, ^Z to exit: "
read (*,*,end=999) x

! Save the FP status values
call IEEE_GET_STATUS (STATUS_VALUE)
! Set all of the flags to quiet
call IEEE_SET_FLAG(IEEE_ALL, .FALSE.)
! Do the SQRT
y = sqrt(X)
! Did we get an "invalid" error?
call IEEE_GET_FLAG (IEEE_INVALID, FLAG)
if (FLAG) then
  write (*,'(A)') "Invalid!"
else
  write (*,'(A,G11.4)') "Value is ", Y
end if
! Restore the status
call IEEE_SET_STATUS(STATUS_VALUE)
end do
999 end[/plain]

[g_f_thomas]

Quoting - Steve Lionel (Intel)

I'm not completely sure what you're asking.

Module IEEE_EXCEPTIONS and IEEE_ARITHMETIC have inquiry functions such as IEEE_SUPPORT_FLAG and IEEE_SUPPORT_NAN to ask about the FP environment to see if certain features are supported.

For a situation such as SQRT(-3), this can be detected by asking if the exception IEEE_INVALID occurred. Here's an example.

[plain]program ieee_test
use, intrinsic :: IEEE_ARITHMETIC
use, intrinsic :: IEEE_FEATURES
implicit none

real x, y
type(IEEE_STATUS_TYPE) STATUS_VALUE
logical flag

do
write (*,'(A)',ADVANCE="NO") "Enter value, ^Z to exit: "
read (*,*,end=999) x

! Save the FP status values
call IEEE_GET_STATUS (STATUS_VALUE)
! Set all of the flags to quiet
call IEEE_SET_FLAG(IEEE_ALL, .FALSE.)
! Do the SQRT
y = sqrt(X)
! Did we get an "invalid" error?
call IEEE_GET_FLAG (IEEE_INVALID, FLAG)
if (FLAG) then
  write (*,'(A)') "Invalid!"
else
  write (*,'(A,G11.4)') "Value is ", Y
end if
! Restore the status
call IEEE_SET_STATUS(STATUS_VALUE)
end do
999 end[/plain]

Sorry for asking, but where in the ivf docs are these two intrinsics documented?

Gerry

[Steven_L_Intel1]

No need to be sorry. It was a surprise to me, but we have not documented them. You can get a copy of the Fortran 2003 standard here - it explains it better than we'd be able to manage.

[g_f_thomas]

Quoting - Steve Lionel (Intel)

No need to be sorry. It was a surprise to me, but we have not documented them. You can get a copy of the Fortran 2003 standard here - it explains it better than we'd be able to manage.

OK, can the IEEE_A/E/F .f90's be copied from 11.../include to say 10.../include, recompiled and now you have the f2003 IEEE TR functioning in 11 and 10? This is predicated on the impression that TR's are open source, standalone, and compiler version neutral.

Gerry

[Steven_L_Intel1]

No, sorry. There is some library support in there, as well as some compiler knowledge (especially related to IEEE_FEATURES). I am not sure what you mean by "TR's are open source, standalone and compiler version neutral". The specification of the IEEE FP intrinsic modules is public, of course, but there is no canonical implementation of the routines. In particular, the compiler has some awareness that these modules are being used so that it can disable optimizations that would interfere (/fp:strict mode, more or less.)

We're somewhat unusual in that we put as much of the intrinsic modules as we can into Fortran source, but there's parts of the implementation which are inside the run-time library.

[g_f_thomas]

Quoting - Steve Lionel (Intel)

No, sorry. There is some library support in there, as well as some compiler knowledge (especially related to IEEE_FEATURES). I am not sure what you mean by "TR's are open source, standalone and compiler version neutral". The specification of the IEEE FP intrinsic modules is public, of course, but there is no canonical implementation of the routines. In particular, the compiler has some awareness that these modules are being used so that it can disable optimizations that would interfere (/fp:strict mode, more or less.)

We're somewhat unusual in that we put as much of the intrinsic modules as we can into Fortran source, but there's parts of the implementation which are inside the run-time library.

Thanks for clarification. I clicked on the f2003 link and now realize that the IEEE feature is not an add-on TR like the infamous variable string stuff. And of course its implementation is proprietary which doesn't bother me in the least.

I acquired from wherever the source of a mixed language (VC++/CVF Fortran) project which illustrates how the IEEE modules are implemented (based on WG5 N1281, 16 June 1997) with VC++ being used for error handling. It works fine with CVF but not with IVF which doesn't have MATHERRQQ.

Anyway, I don't recall any posts to the forum on the IEEE feature which suggests it's not being widely used. I have a comment on its utility. The Fortran Floating Point properties could do some of the boilerplate drudge consistent with the capabilities of the target processor, selected FP properties, use of processor extensions, etc. Also it is not clear how this feature impacts the use of traceback.

BTW, some time ago you indicated that the ability to do SEH within an IVF DLL would be fixed since it was broken at some point in 10. Do you know if this made into 11.0.066?

Gerry

[Steven_L_Intel1]

The IEEE intrinsic modules are new to Intel Fortran 11, and there aren't many other compilers which support them either, so I would not expect wide adoption at this point. Eventually people will discover and use them, but there aren't many applications where such control over the FP environment is desired. For those that need it, the modules provide better control than previous extensions.

This feature does not affect traceback, as far as I know. It is not relying on SEH but rather the processor's control of floating point operations in a portable fashion.

If the exception handling issue with DLLs is the one I think it is (our internal ID DPD200036381), then it is fixed in 10.1 and 11.0.

[g_f_thomas]

Quoting - Steve Lionel (Intel)

The IEEE intrinsic modules are new to Intel Fortran 11, and there aren't many other compilers which support them either, so I would not expect wide adoption at this point. Eventually people will discover and use them, but there aren't many applications where such control over the FP environment is desired. For those that need it, the modules provide better control than previous extensions.

This feature does not affect traceback, as far as I know. It is not relying on SEH but rather the processor's control of floating point operations in a portable fashion.

If the exception handling issue with DLLs is the one I think it is (our internal ID DPD200036381), then it is fixed in 10.1 and 11.0.

Thanks, I'll check into ID DPD200036381. I hope it's the one.

The biggest drawback to the IEEE feature is that it's lacks set and forget it convenience. You have to anticipate where things could go wrong and so lace your code all over the place, maybe, to take reactive action. This contrasts with SEH centralized handling, not just for fp problems, but everything else Fortran 'Windowing' throws at you.

Gerry