In testing with nvfortran 25.9, I hit a bug in the compiler. This code works with every compiler I can test–ifort, ifx, nagfor, gfortran, flang–but nvfortran fails. The code is:
program test
use ieee_arithmetic
implicit none
logical :: set_halting_allowed = ieee_support_halting(ieee_invalid) .and. &
ieee_support_halting(ieee_overflow) .and. &
ieee_support_halting(ieee_divide_by_zero) .and. &
ieee_support_halting(ieee_underflow) .and. &
ieee_support_halting(ieee_inexact)
print *, "IEEE arithmetic support for halting on exceptions:"
print *, "Invalid operation:", ieee_support_halting(ieee_invalid)
print *, "Overflow:", ieee_support_halting(ieee_overflow)
print *, "Divide by zero:", ieee_support_halting(ieee_divide_by_zero)
print *, "Underflow:", ieee_support_halting(ieee_underflow)
print *, "Inexact result:", ieee_support_halting(ieee_inexact)
print *, "Halting on exceptions is supported:", set_halting_allowed
end program test
With nvfortran 25.9:
> nvfortran test_fails.F90
NVFORTRAN-S-0087-Non-constant expression where constant expression required (test_fails.F90: 5)
NVFORTRAN-S-0087-Non-constant expression where constant expression required (test_fails.F90: 5)
NVFORTRAN-S-0087-Non-constant expression where constant expression required (test_fails.F90: 5)
NVFORTRAN-S-0087-Non-constant expression where constant expression required (test_fails.F90: 5)
NVFORTRAN-S-0087-Non-constant expression where constant expression required (test_fails.F90: 5)
0 inform, 0 warnings, 5 severes, 0 fatal for test
Huh. Well that is interesting. Maybe it’s fixed in flang 22?
On my mac with flang 21:
❯ flang --version
Homebrew flang version 21.1.2
Target: arm64-apple-darwin24.6.0
Thread model: posix
InstalledDir: /Users/mathomp4/.homebrew/brew/Cellar/flang/21.1.2/libexec
Configuration file: /Users/mathomp4/.homebrew/brew/Cellar/flang/21.1.2/libexec/flang.cfg
Configuration file: /Users/mathomp4/.homebrew/brew/etc/clang/arm64-apple-darwin24.cfg
~/F90Files/IeeeNVHPCIssue with zsh at 11:41:13 AM
❯ flang test_fails.F90 && ./a.out
error: Semantic errors in test_fails.F90
./test_fails.F90:5:37: error: Initialization expression for 'set_halting_allowed' (__builtin_ieee_support_halting(__builtin_ieee_flag_type(flag=1_1)).and.__builtin_ieee_support_halting(__builtin_ieee_flag_type(flag=8_1)).and.__builtin_ieee_support_halting(__builtin_ieee_flag_type(flag=4_1)).and.__builtin_ieee_support_halting(__builtin_ieee_flag_type(flag=16_1)).and.__builtin_ieee_support_halting(__builtin_ieee_flag_type(flag=32_1))) cannot be computed as a constant value
logical :: set_halting_allowed = ieee_support_halting(ieee_invalid) .and. &
^
and on a machine with a version of flang built off of main a couple months ago:
> flang --version
flang version 22.0.0git (git@github.com:GEOS-ESM/build-llvm-flang.git 76c440f5619a503f59e4b6585076c11a04568c13)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /ford1/share/gmao_SIteam/llvm-flang/2025-07-28/bin
mathomp4 on gs6101-bucy in ~/F90Files/IeeeNVHPCIssue
> flang test_fails.F90 && ./a.out
IEEE arithmetic support for halting on exceptions:
Invalid operation: T
Overflow: T
Divide by zero: T
Underflow: T
Inexact result: T
Halting on exceptions is supported: T
I filed this as TPR #37876 and sent it to engineering. The work around would be to use runtime, rather than static, initialization. See below.
I tested against our upcoming new LLVM based nvfortran compiler, and it works there. I’m not sure on the upstream flang, but it does sound like they may have fixed it already.
Example work around:
% cat test2.F90
program test
use ieee_arithmetic
implicit none
logical :: set_halting_allowed
set_halting_allowed = ieee_support_halting(ieee_invalid) .and. &
ieee_support_halting(ieee_overflow) .and. &
ieee_support_halting(ieee_divide_by_zero) .and. &
ieee_support_halting(ieee_underflow) .and. &
ieee_support_halting(ieee_inexact)
print *, "IEEE arithmetic support for halting on exceptions:"
print *, "Invalid operation:", ieee_support_halting(ieee_invalid)
print *, "Overflow:", ieee_support_halting(ieee_overflow)
print *, "Divide by zero:", ieee_support_halting(ieee_divide_by_zero)
print *, "Underflow:", ieee_support_halting(ieee_underflow)
print *, "Inexact result:", ieee_support_halting(ieee_inexact)
print *, "Halting on exceptions is supported:", set_halting_allowed
end program test
% nvfortran test2.F90; a.out
IEEE arithmetic support for halting on exceptions:
Invalid operation: T
Overflow: T
Divide by zero: T
Underflow: T
Inexact result: T
Halting on exceptions is supported: T
@MatColgrove Greetings from the past. I haven’t passed you a 4000-line CUDA Fortran kernel in ages. :D
And glad to hear “nvflang” is still on the way, we are looking forward to it. Though, at the moment, we have a big ol’ ICE with LLVM that we can’t really get around:
If you have any sway with them, would be nice to get it looked at.
I don’t have sway on the upstream, but I was able to reproduce the error in our development LLVM front-end compiler. I reported to our internal LLVM repo as issue #1570 to see if we can fix it there and then hopefully get the fix uptreamed.
A blessed thank you, @MatColgrove ! It’s hard sometimes to get LLVM’s attention as, well, big community and louder voices win. And NVIDIA has a big voice :D
I talked with a few our engineers about static initialization for “ieee_support_halting”. For x86 it may be doable, but for ARM, probably not. They said that different ARM chips may or may not support raising these exceptions so we have to wait till runtime to check which architecture the binary is running on. Setting these statically at compile time could cause issues.
Also, this might explain the flang errors you and Mass are seeing. The flang failure you saw was on ARM with the success on x86, so it likely has nothing to do with the flang version but the target architecture.
Though you’re best bet overall might actually just use the work around of setting this at runtime rather than statically.
Unfortunately the Apple ARM environment does not support halting properly, so yes, ieee_set_halting_mode is expected to terminate with an error.
and so we added the “all-in-one” setting of set_halting_allowed. It’s not much work to then do it in two steps. (Weirdly though, I thought I’d already merged that change in, but I don’t see a PR or branch. Time to go explore my folders…)
Sounds good. I told engineering that they can either implement this on x86, or just close it. They likely will just close it given we’re not too far off getting the LLVM based front-end into open beta.