Hello,
I’ve just deployed nvhpc-22.2 on a Redhat8 OS. The hardware is Zen2 cpu and A100 GPU. I’m trying to build a large fortran code based on mix parallelism MPI + OpenMP. My goal is to start whith the GPU using OpenMP directives for offloading (no offloading yet).
But I’m unable to build the CPU binary with this version of mpifort/nfvortran. I’m stuck with a strange error message that I do not understand at all at compile time for one file:
/opt/nvidia/hpc_sdk/Linux_x86_64/22.2/compilers/share/llvm/bin/opt: /tmp/nvfortranxnW3f34dyQW_.ll:102919:21: error: use of undefined value '%L.LB26_8163'
br i1 %862, label %L.LB26_8163, label %L.LB26_9035, !dbg !308090
I’ve tried to remove the -g option (may be the “dbg” part could be related to this option
I’ve tried to set -tp=zen2 to set the right cpu flavor
No change.
My main options used are: -mp=gpu -gpu=cc80 -target=gpu -Mstandard -Mpreprocess
These are the ones I used for my smalls tests cases using OpenMP offloading before working on this large code
It’s a compiler issue though exactly what’s causing it is unclear. Are you able to provide a reproducing example that I can use to report the issue to our engineers?
I’m encountered the same problem like yours, either i commented the last 4 functions or all the functions in the file but last 4, it will pass the compilation. while my program is a c++ program
Hi Mat,
Sorry, I just realize my answer was still waiting to be sent…
My solution was to split the file. Another one is to use a lower level of optimization.
For my fortran code, problem is not solved with latest nvidia compilers, I must still downgrade from -O2 to -O1 for this file.
I do not know if I can build a small test-case, this file requires many modules for compilation and I was unable to reproduce with small example.
While the two reports share similar error messages, it’s unlikely that the root cause of the errors are the same given the different languages. Though it’s possible, so checking against 23.3 where the other issue was fixed, wouldn’t hurt.
Is this llc in /nvhpc …/compilers/share/llvm read with wrong *.ll file?
No. These types of errors are due to compiler optimizations not reading the wrong intermediary file.
Hi Mat, is the nvc++ compile from *.cpp to *.ll with something wrong?
Are you asking if the issue is with our front-end compilation or the back-end code generator? Not knowing what the root cause is, I can’t answer that.
I’m using nvc++ to compile C++. When I add -mp, It will failed with error of using undefined value like this,
So I try to get the LLVM IR file *.ll. This file is a temp file in /tmp.
I think this may be a front-end compilation issue. It must not be a back-end issue.
Add the flag “-Mkeepllvm” to keep the intermediary files. They’ll be places in the same directory as the compile rather than tmp.
Though, keeping the .ll file probably wont help you much. Instead, if you can provide a reproducing example which recreates the error, I can then file an issue report.
OK, thanks.
I will try as your comments.
Does nvc++ compile with the same *.cpp with same flag will generate *.ll with the same text?
I compared the LLVM IR file of repeated compile, found the files are different.
Originally I assumed the intermediary files do not change with the same flag, so I can compare LLVM IR files with -mp flag or not.
I’m also confused about the compilers flag difference, something like -fopenmp in g++ and -mp in nvc++.
It feels like the g++ using openmp with a external lib as dependency, while nvc++ using openmp only with a flag -mp. Was it real or just my fantasy?
There’s two parts to OpenMP. There’s the compilation part to process the pragma/directives which is enabled via a compiler flag such as -fopenmp or -mp (we accept either), and then there is the runtime library, libgomp for GNU and libnvomp for NVHPC.
Typically adding the same OpenMP compiler flag to link will also have the compiler implicitly add the OpenMP runtime library. In our case, we always include nvomp on the link unless “-nomp” is added. We do this so CPU core binding support is there even for non-OpenMP programs.
Does nvc++ compile with the same *.cpp with same flag will generate *.ll with the same text?
It should generate the same code each time, though there might slight ordering differences for things like the struct definitions. So a diff might not be exact for the items where order doesn’t matter, but a side by side comparison of the code blocks should be the same.
Thanks.
When I use build tool meson and set omp_dep = dependency('openmp', language:'cpp')with nvhpc compiler.
It will failed with ERROR: Dependency “openmp” not found, tried system.
Does this mean my nvhpc being installed wrong, so pkg-config or cmake can not find it .
This is a small reproducing example. Describe the bug
I’m trying buid a c++ project with nvidia HPC compiler with openmp . This project compiled with meson.
When I using default compiler (gcc c++) with openmp, it’s OK.
But nvidia hpc compiler is failed.
Given this is an issue with Meson, they’ll be in a better position to help you.
Though when I did a web search for this error, it seems that it’s been reported before. Looks to be a configuration issue where when we re-branded from PGI to the NVHPC Compiler, it fails to use the correct preprocessing flags. Appears to work if you use the PGI driver (pgcc) rather than nvc.