Hi,
I compiled code on Ubuntu (20) and Debian (bullseye) and noticed some discrepancies which I would like to know if they are defined behavior.
Note that the same packages containing the HPC SDK was installed on both machines (nvhpc-22-1_22.1_amd64.deb & nvhpc-2022_22.1_amd64.deb).
-
On Ubuntu cmake 3.20 ~ recognizes the compiler freshly installed from https://developer.nvidia.com/nvidia-hpc-sdk-downloads as
NVHPC(usingCMAKE_CXX_COMPILER_ID), on Debian (cmake 3.18) its recognized asPGI. I know nvc is derived from pgi but why the discrepancy ? -
On Debian bullseye I can’t compile due to the following error:
"/usr/include/x86_64-linux-gnu/bits/socket.h", line 285: error: incomplete type is not allowed
__extension__ unsigned char __cmsg_data __flexarr; /* Ancillary data. */
Without going too deep into header stuff, I noticed that the -A option (aka, “Accept ANSI standard C++”) on pgi triggers the issue. When using CMake you can switch ON/OFF the CXX_EXTENSIONS property which controls which version of a cpp standard you want to compile for (-std=c++14 for instance). When turned ON, this property can be translated by gnuc++XX (gnuc++14 for instance) on clang and gcc; that is, “allow” language extensions. When turned OFF, the translation would be c++XX (c++14 for instance). On the HPC SDK, CMake 3.18 and Debian bullseye and using nvc++, when turned ON this is translated to --gnu_extensions, when OFF, this option is translated to -A.
TLDR; The -Aoption breaks the gnu libc. This is problematic at least because pgi defines __GNUC__, and because even if g++ is given -std=c++14, that is, no c++ extensions (which is the opposite of gnu++14) it can consume the gnu libc.
The following code compiled using nvc++ dummy.cc -c -A will trigger the issue):
#include <netdb.h>
Thanks