Re: ifort raises a SIGSEGV when evaluating "NaN >= 0"

Zaikun · ‎12-20-2022

Code:

program test_fpe
use, intrinsic :: ieee_arithmetic, only : ieee_value, ieee_quiet_nan, ieee_is_nan

implicit none

real :: a

a = ieee_value(a, ieee_quiet_nan)

print *, a, ieee_is_nan(a)
print *, a <= 0

end program test_fpe

Result:

$ uname -a && ifort --version && ifort -standard-semantics -fp-stack-check -fpe-all=0 -traceback test_fpe.f90 && ./a.out   
Linux zX10 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
ifort (IFORT) 2021.7.1 20221019
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

 NaN T
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007F6B70EA9520  Unknown               Unknown  Unknown
a.out              0000000000406E94  Unknown               Unknown  Unknown
a.out              0000000000403A03  Unknown               Unknown  Unknown
libc.so.6          00007F6B70EA9520  Unknown               Unknown  Unknown
a.out              000000000045C973  Unknown               Unknown  Unknown
a.out              00000000004044EC  Unknown               Unknown  Unknown
a.out              0000000000404BE7  MAIN__                     11  test_fpe.f90
a.out              00000000004049DD  Unknown               Unknown  Unknown
libc.so.6          00007F6B70E90D90  Unknown               Unknown  Unknown
libc.so.6          00007F6B70E90E40  __libc_start_main     Unknown  Unknown
a.out              00000000004048F5  Unknown               Unknown  Unknown

Note that a SIGSEGV is raised. This is reproduced on Compiler Explorer , where an FPE is raised before the SIGSEGV.

Is this SIGSEGV expected? This renews my understanding of SIGSEGV. According to Wikipedia, SEGFAULT means “the software has attempted to access a restricted area of memory”. I am wondering, what is that restricted area of memory in this case?

Thank you for your attention.

Steve_Lionel · ‎12-20-2022

Don't use -fpe0 or -fpe-all=0 if you're going to be playing with NaNs or denormals. Do use -fp-model=strict.

I note that the segfault you got is in libc - not sure what is going on there. I can't reproduce the segfault on Windows.

-fp-stack-check is only for 32-bit code that uses x87 instructions rather than SSE. It does nothing for you here.

Zaikun · ‎12-20-2022

Thank you for pointing this out.

If -fp-stack-check is removed, then the SEGFAULT does not occur, and an FPE occurs instead. I agree that -fp-stack-check does nothing useful here, but it does do something significant.

ifort -standard-semantics -fpe-all=0 -traceback test_nan_fpe.f90 && ./a.out
 NaN T
forrtl: error (65): floating invalid
Image              PC                Routine            Line        Source             
libc.so.6          00007F4C14701520  Unknown               Unknown  Unknown
a.out              000000000045C693  Unknown               Unknown  Unknown
a.out              00000000004044EC  Unknown               Unknown  Unknown
a.out              0000000000404AA5  MAIN__                     11  test_nan_fpe.f90
a.out              00000000004049DD  Unknown               Unknown  Unknown
libc.so.6          00007F4C146E8D90  Unknown               Unknown  Unknown
libc.so.6          00007F4C146E8E40  __libc_start_main     Unknown  Unknown
a.out              00000000004048F5  Unknown               Unknown  Unknown
Aborted (core dumped)

jimdempseyatthecove · ‎12-20-2022

FWIW an interesting observation is that the error occurred in libc and not in the machine code generated by Fortran.

The print statement where the failure occurred should have resolved the expression "a <= 0" into a logical variable.

Of note here, you are using "a <= 0" as opposed to "a <= 0.0", iow, there is an integer to float conversion going on.

What happens when you use 0.0?

Jim Dempsey

Zaikun · ‎12-20-2022

Hi, thank you for the observation. Even if 0 is replaced with 0.0, the result is exactly the same.

ifort -standard-semantics -fp-stack-check -fpe-all=0 -traceback test_nan_fpe.f90 && ./a.out
 NaN T
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libc.so.6          00007FA81035B520  Unknown               Unknown  Unknown
a.out              0000000000406E76  Unknown               Unknown  Unknown
a.out              0000000000403A0A  Unknown               Unknown  Unknown
libc.so.6          00007FA81035B520  Unknown               Unknown  Unknown
a.out              000000000045C833  Unknown               Unknown  Unknown
a.out              00000000004044EC  Unknown               Unknown  Unknown
a.out              0000000000404BE7  MAIN__                     11  test_nan_fpe.f90
a.out              00000000004049DD  Unknown               Unknown  Unknown
libc.so.6          00007FA810342D90  Unknown               Unknown  Unknown
libc.so.6          00007FA810342E40  __libc_start_main     Unknown  Unknown
a.out              00000000004048F5  Unknown               Unknown  Unknown
make: *** [Makefile:102: test_nan_fpe] Error 174

Ron_Green · ‎12-20-2022

It is interesting. I see the issue on Linux and macOS with IFORT. I don't see any issue with gfortran 12.1 or IFX 2023.0.0

Ifort must be doing something in the math libs. Well if you want to use non-signaling NaNs you can use the IEEE functions to do so. Like this below. Or switch over to IFX 2023.0.0

program test_fpe
use, intrinsic :: ieee_arithmetic, only : ieee_value, ieee_quiet_nan, ieee_is_nan, ieee_quiet_le

implicit none

real :: a

a = ieee_value(a, ieee_quiet_nan)

print *, a, ieee_is_nan(a)

!print *, a <= 0.0
print *, ieee_quiet_le(a,0.0)

end program test_fpe

and the run

ifort -O0 -g -traceback -fpe=0 qnew2.f90 
./a.out
            NaN T
 F

Zaikun · ‎12-20-2022

Thank you @Ron_Green for the response.

1. Thank you for directing me to ieee_quiet_le. However, in practice, it is impossible to know which piece of data will/may become NaN. Therefore, one would have to replace all comparisons (<, >, <=, >=, etc) with ieee_quiet_xx to avoid the problem. This does not sound very practical.

2. I hope to mention that my example is minimal, in the sense that the SEGFAULT will not occur if you remove any option among -standard-semantics , -fp-stack-check , and -fpe-all=0.

3. ifx does not support -fp-stack-check (as mentioned above, this option is useless these days). Therefore, it is unsurprising that the SEGFAULT cannot be reproduced (see last point).

4. RE: "Ifort must be doing something in the math libs." This is interesting. Is ifort doing something right or wrong? Is it possible that we are encountering a bug? If yes, would you mind filing a bug report?

Thank you very much for everything!