Bug of nvfortran 24.3-0: "fort1 TERMINATED by signal 11"

zaikunzhang · April 9, 2024, 5:45pm

Hi,

This is a bug of nvfortran 24.3-0.

To reproduce it, run

git clone https://github.com/libprima/prima.git && cd prima/fortran/common && git checkout d86b5b29e12c81e5c52ddf2f5dfe20bac5725953 && nvfortran -c consts.F90

You will get

Cloning into 'prima'...
remote: Enumerating objects: 50310, done.
remote: Counting objects: 100% (1206/1206), done.
remote: Compressing objects: 100% (386/386), done.
remote: Total 50310 (delta 908), reused 1079 (delta 794), pack-reused 49104
Receiving objects: 100% (50310/50310), 20.58 MiB | 2.79 MiB/s, done.
Resolving deltas: 100% (40479/40479), done.
Note: switching to 'd86b5b29e12c81e5c52ddf2f5dfe20bac5725953'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at d86b5b29 240410.005928.HKT revise cmake.yml

nvfortran-Fatal-/opt/nvidia/hpc_sdk/Linux_x86_64/24.3/compilers/bin/tools/fort1 TERMINATED by signal 11

Note:

As in the last line of log above, the error is
“nvfortran-Fatal-/opt/nvidia/hpc_sdk/Linux_x86_64/24.3/compilers/bin/tools/fort1 TERMINATED by signal 11”, which seems to be an ICE.
The code that reproduces the bug is publicly available on GitHub. (N.B.: Not the latest commit, but commit d86b5b29e12c81e5c52ddf2f5dfe20bac5725953).
You can also download fortran/common/consts.F90 from the above address and trigger the bug by

nvfortran -c consts.F90

The following line (Line 161) of the above code causes the error.

real(RP), parameter :: TINYCV = TEN**max(-60.0, -real(MAXPOW10))

Thank you for taking a look.

MatColgrove · April 9, 2024, 6:40pm

Thanks zaikunzhang,

I filed a problem report, TPR #35501, and sent it to engineering for investigation.

I did find that I can work around the error by using integers instead of reals as max’s arguments.

real(8), parameter :: TINYCV = TEN**max(-60, -MAXPOW10)

-Mat

zaikunzhang · April 9, 2024, 11:23pm

Thank you Mat.

You are right. Indeed, I changed from integer exponent to real to circumvent another bug from another compiler, and then I found this one. See

https://github.com/libprima/prima/blob/285d2b1583d0cddbe58b66704bcb55d36079ea77/fortran/common/consts.F90#L158-L165

https://fortran-lang.discourse.group/t/flang-new-19-0-warning-overflow-on-power-with-integer-exponent/7801/3

MatColgrove · April 10, 2024, 3:00pm

For the flang warning, either add the “-r8” flag to change the default kind of reals to “8”, or set 10.0 to 10.0_8. The overflow is with the single precision real.

zaikunzhang · April 10, 2024, 3:32pm

The flang warning has been confirmed as a bug:

https://github.com/llvm/llvm-project/issues/88151#issuecomment-2045874182

I use single precision on purpose. Thank you.

MatColgrove · April 10, 2024, 3:37pm

Sounds good, looks like Peter, our lead flang developer, is on it.

FYI, we’re one of the primary contributors to new flang which, once feature complete, will likely replace our nvfortran. So flang issues are of interest to us as well.

zaikunzhang · April 11, 2024, 7:48am

FYI, we’re one of the primary contributors to new flang which, once feature complete, will likely replace our nvfortran. So flang issues are of interest to us as well.

Thank you for letting me know.

Indeed, I spotted a new bug in flang-new yesterday. See

github.com/llvm/llvm-project

flang-new: forcing arrays to be allocated on the heap and a possible bug

opened 02:25AM - 11 Apr 24 UTC

zaikunzhang

flang

This is related to https://github.com/llvm/llvm-project/issues/56018. Accord…ing to https://github.com/llvm/llvm-project/issues/56018 , `flang -mmlir -fdynamic-heap-array` should force dynamic arrays to be allocated on the heap and hence avoid stackoverflows when large dynamic arrays are present. The example mentioned at https://github.com/llvm/llvm-project/issues/56018 works but the following does not. ```fortran ! array.f90 module outprod_mod contains function outprod(y, z) result(x) implicit none real, intent(in) :: y(:), z(:) real :: x(size(y), size(z)) integer :: i, j, n, m m = size(y) n = size(z) do i = 1, m do j = 1, n x(i, j) = y(i) * z(j) end do end do end function end module outprod_mod program prog use outprod_mod, only : outprod implicit none integer, parameter :: k = 10000 integer :: i real :: y(k) y = 1.0 do i = 1, k write (*, *) i, size(outprod(y(1:i), y(1:i))) end do end ``` With flang-new, it crashes with a segfault as follows. ```text $ uname -a && flang --version && flang -fno-stack-arrays -mmlir -fdynamic-heap-array -o array array.f90 && ./array Linux 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64 x86_64 x86_64 GNU/Linux flang-new version 19.0.0git (git@github.com:llvm/llvm-project.git 37c175af955f0aeab67e8c553a0a47b2ed0fdba2) Target: x86_64-unknown-linux-gnu Thread model: posix ... ... 1445 2088025 1446 2090916 Segmentation fault (core dumped) ``` Questions: - How to effectively force dynamic arrays to be allocated on the heap? - `-fdynamic-heap-array` alone cannot be recognized by the compiler. It must be `-mmlir -fdynamic-heap-array`. Is this intended? Notes: - `ulimit -s unlimited` seems to help, but we need a solution on flang's side. - Compiled with Classic Flang 15.0.3 without any flags, the code runs fine. Thank you for taking a look.

Are you interested if I inform you about future bugs I spot in flang-new? If yes, what should I do? Should I creat a post here on this forum?

Thanks.

MatColgrove · April 11, 2024, 4:12pm

Are you interested if I inform you about future bugs I spot in flang-new?

It’s best to keep sending issues to them directly since it’s a community project and we’re not the only contributor.

I can help as well, but they are usually responsive.

phil.hasnip · September 24, 2024, 2:47pm

Quick side-note: real(8) is not portable, I recommend using kind real64 from the iso_fortran_env intrinsic module.

Topic		Replies	Views
Issues with REAL(3f) in nvfortran nvc, nvc++ and nvfortran	5	580	April 19, 2021
A bug of `nvfortran` 21.11 nvc, nvc++ and nvfortran nvbugs	9	1546	April 2, 2022
nvfortran-Fatal fort2 TERMINATED by signal 11 nvc, nvc++ and nvfortran	6	1440	May 20, 2024
Internal compiler error with nvfortran 22.9 nvc, nvc++ and nvfortran	4	560	November 16, 2022
Another segmentation fault with compiled nvfortran code nvc, nvc++ and nvfortran nvbugs	2	795	April 20, 2023
NVFORTRAN bug nvc, nvc++ and nvfortran nvbugs	1	758	November 23, 2021
Segfault connected to procedure pointer in nvfortran nvc, nvc++ and nvfortran	1	424	June 3, 2021
Internal compiler error in OOP Fortran code nvc, nvc++ and nvfortran	2	729	April 4, 2023
Compiler Error in nvfortran 23.11 and 23.7 nvc, nvc++ and nvfortran	2	528	December 14, 2023
Nvfortran rejects valid code nvc, nvc++ and nvfortran nvbugs	1	202	September 27, 2024

Bug of nvfortran 24.3-0: "fort1 TERMINATED by signal 11"

Related topics