# Bug or programmer error? **URL:** \ **Category:** NVIDIA\ **Created:** [July 16, 2025, 2:23am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927 "2025-07-16T02:23:37Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\ **Post date:** [July 16, 2025, 2:23am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/1 "2025-07-16T02:23:37Z")
I am playing around with using do concurrent for GPU offloading and multicore architectures, I wrote a very simple daxpy which I’ve uploaded [here](https://github.com/JorgeG94/nvfortran-dc-bug/tree/main). I am using the 25.5 version of nvfortran. In short, for the sizes: ```auto integer(int64), parameter :: n1 = 1024_int64*1024_int64*1024_int64*1_int64 integer(int64), parameter :: n2 = 1024_int64*1024_int64*1024_int64*2_int64 integer(int64), parameter :: n3 = 1024_int64*1024_int64*1024_int64*3_int64 integer(int64), parameter :: n4 = 1024_int64*1024_int64*1024_int64*4_int64 ``` I perform a daxpy between vectors B = 3.0\_dp \*A + B, where B is initialized to `0.0_dp` and A to `1.0_dp` I compile with `nvfortran -O3 fail.f90` and alternate between using `-stdpar=multicore`. In the github you can use `make` and as long as nvfortran is on the path it should work. Without `multicore` enabled my 4 tests pass, doing the daxpy from n1 to n4. With multicore enabled, once I hit n3 my arrays are filled with zeroes. The daxpy in question is just: ```auto subroutine do_daxpy_of_size(n) use, intrinsic :: iso_fortran_env, only: int64 real(dp), parameter :: tol = 1.0e-8_dp real(dp), allocatable :: A(:), B(:) real(dp) :: alpha integer(int64), intent(in) :: n print *, " my size is ", n allocate(A(n), B(n)) do concurrent (i=1:n) A(i) = 1.0_dp B(i) = 0.0_dp end do alpha = 3.0_dp do concurrent (i=1:n) B(i) = alpha * A(i) + B(i) end do call check_array(B, 3.0_dp, tol, n) deallocate(A,B) end subroutine do_daxpy_of_size ``` Is this a bug or am I overlooking something obvious? ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 16, 2025, 4:44am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/2 "2025-07-16T04:44:30Z")
You don’t give a complete code to test, so this is just a guess. Try declaring the loop index `i` to be `int64`. I think the range `1:n` will be alright, despite the fact that the two integers are different kinds, but you might try `1_int64:n` to see if that makes a difference. ---
**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\ **Post date:** [July 16, 2025, 5:33am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/3 "2025-07-16T05:33:46Z")
it’s in the github link [GitHub - JorgeG94/nvfortran-dc-bug](https://github.com/JorgeG94/nvfortran-dc-bug/tree/main) ---
**Author:** ![jkd2022](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jkd2022/32/1949_2.png) [@jkd2022](https://fortran-lang.discourse.group/u/jkd2022)\ **Post date:** [July 16, 2025, 8:35am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/4 "2025-07-16T08:35:58Z")
It’s possible that nvfortran is creating temporary arrays and running out of stack space for the larger values of n. On a Linux machine you can try setting ```auto ulimit -s unlimited ``` or increase the OpenMP stack size per thread (assuming that’s what `do concurrent` uses): ```auto export OMP_STACKSIZE=512M ``` You can also remove the option `-Mstack_arrays` (if it was already set). ---
**Author:** ![Ali](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ali/32/751_2.png) [@Ali](https://fortran-lang.discourse.group/u/Ali)\ **Post date:** [July 16, 2025, 9:04am UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/5 "2025-07-16T09:04:55Z")
It seems there’s a problem when the loop index exceeds the `int32` limit. I ran a test here: [GitHub - gha3mi/nvfortran-dc-bug](https://github.com/gha3mi/nvfortran-dc-bug) ```auto fpm @nv-multicore --verbose ``` Here are the outputs: ```auto n = 1073741824 chunk = 2147483647 huge(int32) = 2147483647 huge(int64) = 9223372036854775807 Initialize : 1.064724000 [s] Elapsed time: 0.947305000 [s] Finalize : 1.265888000 [s] n = 2147483648 chunk = 2147483647 huge(int32) = 2147483647 huge(int64) = 9223372036854775807 Initialize : 2.124329000 [s] Elapsed time: 2.014653000 [s] Finalize : 2.347173000 [s] n = 3221225472 chunk = 2147483647 huge(int32) = 2147483647 huge(int64) = 9223372036854775807 Initialize : 3.274863000 [s] Elapsed time: 2.804645000 [s] Finalize : 3.312508000 [s] n = 4294967296 chunk = 2147483647 huge(int32) = 2147483647 huge(int64) = 9223372036854775807 Initialize : 7.620918000 [s] Elapsed time: 25.498055000 [s] Finalize : 6.859171000 [s] ``` ---
**Author:** ![jorgeg](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jorgeg/32/6835_2.png) [@jorgeg](https://fortran-lang.discourse.group/u/jorgeg)\ **Post date:** [July 16, 2025, 12:46pm UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/6 "2025-07-16T12:46:40Z")
> [@Ali](#): > > It seems there’s a problem when the loop index exceeds the `int32` limit. I ran a test here: I see that you’re also using `i=1_int64,n`, this is interesting ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [July 16, 2025, 5:08pm UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/7 "2025-07-16T17:08:22Z")
> [@jkd2022](#): > > or increase the OpenMP stack size per thread (assuming that’s what `do concurrent` uses): > > `export OMP_STACKSIZE=512M` Is this the correct meaning, or is that OMP\_STACKSIZE value the total size for all of the OpenMP stacks? The documentation is a little ambiguous. ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [July 16, 2025, 8:12pm UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/8 "2025-07-16T20:12:26Z")
I’ve tried a simpler program that does not use arrays, and it also gives an unexpected result with `-stdpar=multicore` and `n = 3 * 10^9` (here, no output from inside `do concurrent`). The code works for `n = 2 * 10^9` and the order of the output becomes irregular (maybe because of threading). Also, the code gives the expected result with ifort & ifx for `n = 3 * 10^9` with `-fopenmp`. (I could not compile it with other compilers.) The assembly code corresponding to the `do concurrent` line (highlighted in different colors) has various `i32` with `-stdpar=multicore`, but I don’t know whether they are related here … Anyway, it seems that the result becomes strange even without arrays, so possibly a compiler bug…? (if the program is no problem) - [Compiler Explorer](https://godbolt.org/z/1zjznj9cK) ```fortran program main call test() end program subroutine test() use iso_fortran_env, only: ip => int64 implicit none integer(ip) :: n, i i = 777 !! n = 2_ip * (10_ip)**9 !! works for nvfort -O3 -stdpar=multicore n = 3_ip * (10_ip)**9 !! works for nvfort -O3 print *, "n = ", n print *, "before: i = ", i do concurrent (i = 1_ip : n) if (mod(i, n / 5_ip) == 0) & print *, "loop: i = ", i end do print *, "after: i = ", i end ``` Results (all with x86 nvfortran-25.5) ```fortran !! -O3 & n = 2 * 10^9 n = 2000000000 before: i = 777 loop: i = 400000000 loop: i = 800000000 loop: i = 1200000000 loop: i = 1600000000 loop: i = 2000000000 after: i = 777 !! -O3 -stdpar=multicore & n = 2 * 10^9 n = 2000000000 before: i = 777 loop: i = 1200000000 loop: i = 400000000 loop: i = 1600000000 loop: i = 800000000 loop: i = 2000000000 after: i = 777 !! -O3 & n = 3 * 10^9 n = 3000000000 before: i = 777 loop: i = 600000000 loop: i = 1200000000 loop: i = 1800000000 loop: i = 2400000000 loop: i = 3000000000 after: i = 777 !! -O3 -stdpar=multicore & n = 3 * 10^9 n = 3000000000 before: i = 777 after: i = 777 ``` ---
**Author:** ![Ali](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ali/32/751_2.png) [@Ali](https://fortran-lang.discourse.group/u/Ali)\ **Post date:** [July 16, 2025, 10:40pm UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/9 "2025-07-16T22:40:27Z")
This simple test also confirms that if a `do concurrent` loop’s range exceeds the `int32` limit (`n2 - s2 > huge(int32)`), the loop fails silently ```fortran program test2 use, intrinsic :: iso_fortran_env, only: int32, int64 implicit none integer(int64), parameter :: s1 = 10_int64 integer(int64), parameter :: s2 = 10_int64 integer(int64), parameter :: n1 = int(huge(int32), kind=int64) + 10_int64 integer(int64), parameter :: n2 = int(huge(int32), kind=int64) + 11_int64 integer(int64) :: i print'(a)', "Test for loop range within int32" print'(a,g0)', "n1 = ", n1 print'(a,g0)', "s1 = ", s1 print'(a,g0)', "n1 - s1 = ", n1 - s1 print'(a,g0)', "huge(int32) = ", huge(int32) do concurrent (i = s1:n1) if (i == n1) print*, "ok" end do print'(a)', "if n1 - s1 <= huge(int32): ok" print*, "" print'(a)', "Test for loop range exceeding int32" print'(a,g0)', "n2 = ", n2 print'(a,g0)', "s2 = ", s2 print'(a,g0)', "n2 - s2 = ", n2 - s2 print'(a,g0)', "huge(int32) = ", huge(int32) do concurrent (i = s2:n2) if (i == n2) print*, "ok" end do print'(a)', "if n2 - s2 > huge(int32): not ok" end program ``` results: ```plaintext Test for loop range within int32 n1 = 2147483657 s1 = 10 n1 - s1 = 2147483647 huge(int32) = 2147483647 ok if n1 - s1 <= huge(int32): ok Test for loop range exceeding int32 n2 = 2147483658 s2 = 10 n2 - s2 = 2147483648 huge(int32) = 2147483647 if n2 - s2 > huge(int32): not ok ``` ---
**Author:** ![JohnCampbell](https://avatars.discourse-cdn.com/v4/letter/j/5daacb/32.png) [@JohnCampbell](https://fortran-lang.discourse.group/u/JohnCampbell)\ **Post date:** [July 23, 2025, 1:01pm UTC](https://fortran-lang.discourse.group/t/bug-or-programmer-error/9927/10 "2025-07-23T13:01:41Z")
I can report that using OpenMP DO loops with n = 4 \*10^9, the do does not have this overflow problem. But if using [equation.com](http://equation.com)’s windows version after Ver 11.1.0 and “call omp\_set\_num\_threads” the program will not terminate! I have been unsuccessful in reporting this problem to [equation.com](http://equation.com) for years ! The following does not exit on my Win10; 12 cpu pc ```auto program main call report_version call test end program subroutine test use iso_fortran_env, only: ip => int64 implicit none integer(ip) :: n, i integer :: id, num logical :: use_omp_set_num_threads = .true. ! .false. ! integer, external :: omp_get_thread_num if ( use_omp_set_num_threads ) then call omp_set_num_threads (10) write (*,*) 'omp_set_num_threads set to',10 write (*,*) 'program may not terminate !!' end if i = 777 num = 8 !! n = 2_ip * (10_ip)**9 !! works for nvfort -O3 -stdpar=multicore n = 4_ip * (10_ip)**9 !! works for nvfort -O3 print *, "n = ", n id = omp_get_thread_num () print *, "before: i = ", i, id !z do concurrent (i = 1_ip : n) !$OMP PARALLEL DO private (i,id) shared (n) num_threads (num) do i = 1_ip, n if (mod(i, n / 13_ip) == 0) then id = omp_get_thread_num () print *, "loop: i = ", i, id end if end do !$OMP END PARALLEL DO id = omp_get_thread_num () print *, "after: i = ", i, id print *, "end of test" end subroutine report_version use iso_fortran_env , only : compiler_version, compiler_options implicit none write (*,*) 'ver : ',compiler_version () write (*,*) 'opt : ',compiler_options () end subroutine report_version ```