Nvfortran in HPC SDK 20.11 complies code that shouldn't compile

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
#1

Hello,

My code is not working properly with HPC SDK 20.11. When debugging the code, I see a puzzling behavior of the nvfortran compiler. It seems to compile a line of code that shouldn’t compile. Both ifort and gfortran report an error at compile time for the same code.

A small, standalone reproducer is attached below. It’s also available at https://github.com/vyu16/test_nvfortran_20_11

ifort -c -o test.o test.f90
test.f90(17): error #8485: There is no matching specific function for this type bound generic function reference.   [GETITEM]
ierr = mapp%getitem(element, 123, "xxx", element)

gfortran -c -o test.o test.f90
test.f90:17:9:

17 |   ierr = mapp%getitem(element, 123, "xxx", element)
   |               1
Error: Found no matching specific binding for the call to the GENERIC 'getitem' at (1)

nvfortran -c -o test.o test.f90
(no error)
nvfortran -o test.x test.o dummy_module.o
(no error)
./test.x
(no error)

Same behavior with pgfortran in PGI 20.4. Any explanation would be appreciated!

Victor

test_nvfortran_20_11-main.zip (2.5 KB)

#2

Thanks Victor,

I asked one of our engineers to take a look and he agrees that we should be issuing an error for this case. I’ve added an issue report, TPR #29370.

-Mat

#3

Hi Mat,

Thanks a lot for your reply. Do you know what’s happening at run time? It appears to me that line 17 just gets ignored at run time. The getitem procedure is not called, as you can see from the output of the program (there’s only one mapping_getitem_chars_int32 printed.). I believe this is related to a bigger issue we are experiencing with nvfortran. The example above was a byproduct when debugging that issue.

Simply put, our “bigger” issue is that we think there’s a valid line of code that, for whatever reason, is not executed at run time. I’m still trying to make a standalone reproducer. But I think it’s quite similar to the example above. The only difference is that we call getitem correctly, but still it’s not executed.

Thanks,
Victor

#4

The engineer that looked at this said “Looks like we are ignoring the extra arguments on the user’s call to the getitem() generic type bound procedure”. So yes, there may be a larger issue here. Definitely if you can get a reproducer that would help the team in finding a fix. Though I’ll add this info to TPR #29370 in case it helps determine the problem.