C++11 Header Files

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

I saw that PGI 15.1 has support for C++11, and I thought I would test it out to see if I could use OpenACC with some C++ code.

But I get stuck at the first hurdle. I am testing the following

#include <type_traits>

using value_type = double;
int main(void) {
    value_type a = 4.;
    auto b = a;

    static_assert(std::is_same<decltype(b), value_type>::value, "bad news");

    return 0;
}

The compiler handles the code just fine (using, auto and static_assert), but if I try to include the type_traits header I get the following error:

"/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/c++0x_warning.h", line 31: catastrophic error: 
          #error directive: This file requires compiler and library support
          for the upcoming ISO C++ standard, C++0x. This support is currently
          experimental, and must be enabled with the -std=c++0x or
          -std=gnu++0x compiler options.
  #error This file requires compiler and library support for the upcoming

I tried to work around this by explicitly using header files provided by a more recent version of gcc (4.8.2), but had the same problem.

Is the C++11 standard library also supported by PGI 15.1? If so, do you have any tips to work around my issue?

2

Hi Ben,

Yes, pgc++ does support C++11. However as you suspect, we need a GNU version installed, such as 4.8.2, that also supports C++11 in order to use the C++11 standard library.

If 4.8.2 was not the default GNU version used when the PGI compilers were installed, you’ll need to create a new PGI configuration file that points to the updated GNU. This is done by running the “makelocalrc” script found in your installation’s build directory and setting the gcc, g++, and gfortran versions to use.

For example:

/opt/pgi/linux86-64/15.3/bin/makelocalrc /opt/pgi/linux86-64/15.3/bin -gcc /path/to/gcc-4.8.2/bin/gcc -gpp /path/to/gcc-4.8.2/bin/g++ -g77 /path/to/gcc-4.8.2/bin/gfortran -x -net

The “-net” flag will create a “localrc.” file in the PGI install’s bin directory with the correct configuration information. Without “-net”, the “localrc” file will be overwritten.

“localrc” is the default configuration to be used by the compilers. A “localrc.” is the configuration for a particular host. In both cases, all users will get this configuration.

If you want the configuration to only apply to your pgc++ compiles, move the created localrc file to your home directory and rename it “.mypgcpprc”.

Apologies that this is a complex process. We are investigating way to make it easier to change which GNU the compilers use. It hadn’t been a problem before but now that pgc++ is object compatible with g++, we have to use the GNU STL.

  • Mat
3

Thanks Mat! I will get somebody with the appropriate permissions to set it up (unless it is possible for me to skip straight to creating the configuration file in my home path).

I have one further question: what is the nature of the dependance on the GNU toolchain? Is it just a dependence on STL/standard library, or is there some dependence in the compiler front end, required to parse the C++11?

Thanks again for the help.

4

Just the STL.

FYI, if happen to be attending GTC 2015, I’ll be giving a talk on C++ and OpenACC. Let me know if you need help.

  • Mat
5

This thread was started in 2015 and Mat then noted that

Apologies that this is a complex process. We are investigating way to make it easier to change which GNU the compilers use. It hadn’t been a problem before but now that pgc++ is object compatible with g++, we have to use the GNU STL.

Is there now an easier way to do this? I’m using pgc++ 19.10.

6

Is there now an easier way to do this? I’m using pgc++ 19.10.

This is becoming less of an issue now that most Linux distributions are using new GNU versions by default.

Though the process of using non-default system GNU versions is the same, i.e. create a new localrc file via the “makelocalrc” script using the options I describe above.

So for example I’m starting to use C++17 more so need a GNU 7.x or later, and many of the systems I use only have GNU 4.9.3 installed. So I’ll create my own localrc files for use with a non-default install of GNU 9.2.

-Mat

7

This static solution is not appropriate for a dynamic environment like a computing center where staff have to deal with hundreds of applications and thousands of users. We have multiple versions of GNU compilers available for use. Why not implement a dynamic solution where the PGI compiler does the appropriate thing based on the currently loaded GCC module?

8

Concerns over overhead. We’d need to essential do the configuration each time the compiler is invoked. While not huge, it is extra overhead that isn’t necessary for the vast majority of compiler installations.

-Mat