Issues with REAL(3f) in nvfortran

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
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

Thanks Urbanjost. This does look like a compiler issue related to the data type conversion of an array section in combination of a write statement. I’ve added a problem report, TPR #29306, and sent it to engineering for further investigation.

As a work around, you can use a temp array to convert the data type:

allocate(arr2,source=real(arr(1::2)))
write(stdout,gen)‘A’,real(arr2)

Full example:

% cat test.f90
program testit
use, intrinsic :: iso_fortran_env, only : stdout=>OUTPUT_UNIT
character(len=*),parameter :: gen='(*(g0,1x))'
integer,allocatable :: arr(:), arr2(:)
   arr=[1,2,3,4,5,6]
   allocate(arr2,source=real(arr(1::2)))
   write(stdout,gen)'A',real(arr(1::2))
   write(stdout,gen)'A2',real(arr2)
   write(stdout,gen)'a',size(real(arr(1::2)))
   write(stdout,gen)'a2',size(real(arr2))
   deallocate(arr2)
   allocate(arr2,source=real(arr(2::2)))
   write(stdout,gen)'B',real(arr(2::2))
   write(stdout,gen)'B2',real(arr2)
   write(stdout,gen)'b',size(real(arr(2::2)))
   write(stdout,gen)'b2',size(real(arr2))
   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)'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 test.f90 ; a.out
A 1.000000 3.000000 5.000000 0. 0. 65.00000
A2 1.000000 3.000000 5.000000
a 6
a2 3
B 2.000000 4.000000 6.000000 0. 0.
B2 2.000000 4.000000 6.000000
b 5
b2 3
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
c 6
d 6
e 3
f 3

Best Regards,
Mat

3

Thanks. Were I first encountered it it did not involve any I/O. It caused different symptoms in different parts of the code, probably because it appears to cause data corruption; but the case was reduced from a call to CMPLX(3f) where the odd values of a real array where used as the real components and the even indices were used as the imaginary component. It either caused a segfault or the calling routine was returned a zero size array. So I do not think it is only tied to I/O.

4

I added a note to the problem report indicating that the issue occurs other than when using the conversion within an I/O statement.

5

thanks

6

This bug has been fixed in all of our 2021 compilers: NVIDIA HPC SDK compiler versions 21.1, 21.2, and 21.3.