Issues with nvfortran REAL() function

To make a long story short that dealt with complex variables and segfaults
and allocatable arrays being defined as size zero that could not be,
I think all the problems have a root cause having to do with REAL() in
nvfortran(1). anyone see any reason ‘A’ and ‘B’ should not be returning
[1,3,5] and [2,4,6] ?

program testit
use, intrinsic :: iso_fortran_env, only : stdout=>OUTPUT_UNIT
character(len=*),parameter :: gen='(*(g0,1x))'
integer,allocatable :: arr(:)
   arr=[1,2,3,4,5,6]
   write(stdout,gen)'A',real(arr(1::2))
   write(stdout,gen)'B',real(arr(2::2))
   write(stdout,gen)'C',real(arr(1:))
   write(stdout,gen)'D',real(arr)
   write(stdout,gen)'E',arr(1::2)
   write(stdout,gen)'F',arr(2::2)

   write(stdout,gen)'a',size(real(arr(1::2)))
   write(stdout,gen)'b',size(real(arr(2::2)))
   write(stdout,gen)'c',size(real(arr(1:)))
   write(stdout,gen)'d',size(real(arr))
   write(stdout,gen)'e',size(arr(1::2))
   write(stdout,gen)'f',size(arr(2::2))
end program testit
nvfortran 20.7-0 LLVM 64-bit target on x86-64 Linux -tp nehalem 
NVIDIA Compilers and Tools
Copyright (c) 2020, NVIDIA CORPORATION.  All rights reserved.
A 1.000000 3.000000 5.000000 0. 0. 16017.00
B 2.000000 4.000000 6.000000 0. 0.
C 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
D 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
E 1 3 5
F 2 4 6
a 6
b 5
c 6
d 6
e 3
f 3

No, why would anyone see any reason for it? REAL(A [, KIND]) intrinsic procedure in the Fortran standard is an ELEMENTAL function after all.

Another thing you can try is take the following code which I contend conforms to Fortran 90 standard published nearly 30 years ago and for which there were quite a few robust conforming compilers. How does NVFORTRAN 20.7-0 perform with this code?

   integer, allocatable :: arr( : )
   allocate( arr(6) )
   arr = (/ 1,2,3,4,5,6 /)
   write( unit=6, fmt="(6(f5.1,1x))") real(arr(1::2))
   write( unit=6, fmt="(6(f5.1,1x))") real(arr(2::2))
   deallocate( arr )
end

Compaq Visual Fortran from way back in year 2003 (or more like DEC Fortran, the predecessor to current Intel Fortran compiler), a processor that attempted to conform to Fortran 95, compiles to yield the following output:

C:\Temp>type p.f90
integer, allocatable :: arr( : )
allocate( arr(6) )
arr = (/ 1,2,3,4,5,6 /)
write( unit=6, fmt="(6(f5.1,1x))") real(arr(1::2))
write( unit=6, fmt="(6(f5.1,1x))") real(arr(2::2))
deallocate( arr )
end

C:\Temp>f90 p.f90
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.

p.f90
Microsoft ® Incremental Linker Version 6.00.8447
Copyright © Microsoft Corp 1992-1998. All rights reserved.

/subsystem:console
/entry:mainCRTStartup
/debugtype:cv
/pdb:none
dfor.lib
libc.lib
dfconsol.lib
dfport.lib
kernel32.lib
/out:p.exe

C:\Temp>p.exe
1.0 3.0 5.0
2.0 4.0 6.0

C:\Temp>

Interesting. With a different compiler I see

./a.out
A 1.000000 3.000000 5.000000
B 2.000000 4.000000 6.000000
C 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
D 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000
E 1 3 5
F 2 4 6
a 3
b 3
c 6
d 6
e 3
f 3

I suspect a bug in the original compiler. Note that REAL() is usually implemented as in-line code, so it’s probably the compiler and not the intrinsics library.

Might be worth reporting this issue at the NVIDIA developer forum:

reported to NVIDIA as an issue

1 Like