[nvhpc-22.2] error: use of undefined value '%L.LB26_8163'

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

Thanks for your help

Hi Patrick,

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?


Hi Mat,
Quite difficult for me as it is a very large file (near 9000 lines) with a lot of dependancies (31 fortran modules are used). Moreover:

  • if I remove the last 2 subroutines, compilation is successfull
  • if I remove all but the last 2 subroutines compilation is successfull too…


Could the size of the file be responsible of the problem ? I will try to split the file to go further.

It’s preferred if it can be a minimal reproducer, but not required. Do your best, but if you need to send the entire project, that’s fine.

Hi patrick

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

Do you find out anything further about this?

Hi luan.dian,

Do you have reproducing example you can share?


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 preferred, the reproducing example doesn’t have to be small. Large is fine as well.

It’s just without any reproducer, we can only hope engineering hits something similar and able to resolve the issue that way.

Hi patrick
This error is similar with Internal compiler error. BAD sptr in var_refsym - HPC Compilers / nvc, nvc++ and nvfortran - NVIDIA Developer Forums
Is this llc in /nvhpc …/compilers/share/llvm read with wrong *.ll file?
Hi Mat, is the nvc++ compile from *.cpp to *.ll with something wrong?

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.


1 Like

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.

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 .

Gnu compiler is ok with this meson.build file.

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.

To Reproduce
meson.build file:

project('nvidiaHPCtest', 'cpp')
ompdep = dependency('openmp')
executable('demo', 'main.cpp', dependencies : ompdep)

main.cpp file:

#include <iostream>
#include <omp.h>

int main(int argc, char **argv) {

#if defined(_OPENMP)
  std::cout << "openmp is defined\n";

  #pragma omp parallel
    std::cout <<"Hello there.\n";
  return 0;

Expected behavior
gcc meson compile command:

 1. meson setup builddir  
 2. cd builddir
 3. ninja

nvidia hpc compile command:
1. CC=/mnt/f/work/nvhpc/Linux_x86_64/23.5/compilers/bin/nvc CXX=/mnt/f/work/nvhpc/Linux_x86_64/23.5/compilers/bin/nvc++ meson setup builddir

It will failed with ERROR: Dependency “openmp” not found, tried system.

note: my nvidia hpc compiler installed in /mnt/f/work/nvhpc/Linux_x86_64/23.5/compilers/bin

system parameters

  • This is a Windows wsl2 Ubuntu subsystem compile
  • Ubuntu 22.04
  • Python 3.10.6
  • meson 0.61.2
  • ninja 1.10.1

I have also post this issue on github #meson build for some comments with meson compile.
meson build error with openmp using nvidia HPC compiler · Issue #11880 · mesonbuild/meson (github.com)

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.

1 Like

OK, thanks.