Issues with nvfortran REAL() function

1

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
2

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

3

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 (R) Incremental Linker Version 6.00.8447
Copyright (C) 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>

4

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.

5

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

6

reported to NVIDIA as an issue

1 Like