Trouble compiling QuantLib with nvc++

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

I’m experimenting with QuantLib on an Ubuntu system with NVidia HPC SDK installed. The code does not have any ACC-pragmas, only the OpenMP ones.

I configure it using the below cmake-command:

cmake .. -DCMAKE_CXX_COMPILER=nvc++ -DQL_USE_PCH=OFF -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_EXTENSIONS=OFF -DCMAKE_CXX_FLAGS="-D BOOST_ENABLE_ASSERT_HANDLER -Xcompiler -march=native -O3 -pipe -std=c++17" -DQL_ENABLE_SESSIONS=ON -DQL_ENABLE_PARALLEL_UNIT_TEST_RUNNER=ON -DQL_USE_STD_CLASSES=ON -DQL_ENABLE_OPENMP=ON

The build succeeds, but there are multiple failures of the bundled self-tests. Invoking the test-suit/quantlib-test-suite executable reports numerous errors with various computed figures not matching the expected values. Many tests succeed, but about 80 fail. For example:

/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 0 (Homogeneous student with step integration on [0 , 0.03]): 5084.62 vs. 1713
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 1 (Inhomogeneous student with midp integration on [0.03 , 0.06]): 0 vs. 359
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 1 (Inhomogeneous student with step integration on [0.03 , 0.06]): 0 vs. 359
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 1 (Homogeneous student with midp integration on [0.03 , 0.06]): 0 vs. 359
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 1 (Homogeneous student with step integration on [0.03 , 0.06]): 0 vs. 359
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 2 (Inhomogeneous student with midp integration on [0.06 , 0.1]): 0 vs. 136
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 2 (Inhomogeneous student with step integration on [0.06 , 0.1]): 0 vs. 136
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 2 (Homogeneous student with midp integration on [0.06 , 0.1]): 0 vs. 136
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 2 (Homogeneous student with step integration on [0.06 , 0.1]): 0 vs. 136
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 3 (Inhomogeneous student with midp integration on [0.1 , 1]): 0 vs. 9
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 3 (Inhomogeneous student with step integration on [0.1 , 1]): 0 vs. 9
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 3 (Homogeneous student with midp integration on [0.1 , 1]): 0 vs. 9
/workspace/QuantLib-1.41/test-suite/cdo.cpp(90): error: in "QuantLibTests/CdoTests/testHW<QuantLibTests__CdoTests__dataSetFive>": case 4 3 (Homogeneous student with step integration on [0.1 , 1]): 0 vs. 9

The QuantLib project are quite good about maintaining the self-tests, and those succeed on the same system, when built with g++ versions 11 and 12, for example. I’ve also successfully built – and tested – this library on RedHat using g++ 14, and on FreeBSD using clang.

What is nvc++ doing, that’s causing the failures – and why, considering the software is not using any ACC-pragmas?

The nvc++ here is of version 25.11-0…

3

Update. Lowering the optimization level to -O0 reduces the number of test-failures significantly, which does suggest a compiler bug…

4

Hi UnitedMarsuplias and welcome!

I started looking at this but see it’s a very large project and given it’s a verification error with one of the unit tests, it will take awhile to dig into it.

Since I’m trying to get ready for a conference I’m attending next week, I’ve asked another DevTech to see if he can investigate. He’ll post once he’s able.

-Mat

5

Replace the -DCMAKE_BUILD_TYPE=Release cmake-flag with a reference to some nonexistent build-type – to prevent cmake from inserting its own optimization flags into it. For example: -DCMAKE_BUILD_TYPE=Meow.

Then, when building, be sure to add VERBOSE=1 to make’s command-line – so as to see the actual commands invoked.