Nvfortran bug with reshape inlining in 20.11

A user on our system is seeing a new error in nvfortran 20.11 that did not occur in 20.9 (or in prior PGI versions). He is compiling a module as part of a standard FFT implementation, and he is using function inlining with reshaping as the code is being integrated into a GPU-offload application. The inlining is done but then LLVM reports the following error:

$ nvfortran -Minfo=inline -Minline=reshape -c singleton.f90
fftradix:
    389, factorize inlined, size=38, file singleton.f90 (403)
    393, transform inlined, size=315, file singleton.f90 (466)
    394, permute inlined, size=185, file singleton.f90 (827)
/glade/u/apps/opt/nvhpc/20.11/Linux_x86_64/20.11/compilers/share/llvm/bin/llc: error: /glade/u/apps/opt/nvhpc/20.11/Linux_x86_64/20.11/compilers/share/llvm/bin/llc: /glade/scratch/vanderwb/temp/nvfortranL8W4VWDthsvg.ll:8500:22: error: use of undefined value '%maxfactor'
        %364 = bitcast i64* %maxfactor to i32*, !dbg !462
                            ^

I can provide the f90 source file and a simple build script.

Please. I can report the issue once we have reproducing example. You can upload it directly in the forum, or message me directly and we can arrange a way to it send it to me.

Thanks,
Mat

Thank you for the reply. Attached is a tarball with the source and build script. We load an environment module to set up the NVIDIA HPC SDK - but otherwise the compute environment is kept simple.

Regards,
Brian

reshape_bug.tar.gz (7.5 KB)

Thanks Brian! I’m able to reproduce the error here and have filed TPR #29535 to track.

Looks to me as if the compiler is loosing track of the parent’s “maxfactor” variable when the contained subroutine is inlined. We’ll have an engineer take a look here soon.

Thanks Mat. Glad to hear it is reproducible. Feel free to reach out to me via email or this forum if needed. We look forward to having a resolution on the error.

Hi Mat - Just wondering if there is any way I can track the progress of the error report? I tried our test case in the recent 21.2 release and noticed that the problem remains, but I am hoping it is resolved in the next release.

Just wondering if there is any way I can track the progress of the error report?

No sorry. Our technical problem reporting (TPR) system is a carry over from PGI (we’ve been using it since the 1990s) and were never able to make it publicly accessible. Though we do update the posts once a fix is available and I’m happy to look up status.

For TPR #29535, it does appear that we have a fix in our development compiler that’s currently undergoing testing. Assuming testing goes well and the fix does not cause other errors, it’s likely to be available in a release in the near future.

1 Like

This fix is indeed in the 21.3 release, available now.