--c++11 and '#include <array>'

Does pgc++ 14.7-0 64-bit target on x86-64 Linux -tp istanbul

supports the C++11 construct

#include <array>

Using a test program:

g++ -std=c++11 -c test-array.cpp
icc -std=c++11 -c test-array.cpp

both work but

pgc++ --c++11 -c test-array.cpp

croaks:

"test-array.cpp", line 3: catastrophic error: cannot open source file "array"
  #include <array>
                  ^
1 catastrophic error detected in the compilation of "test-array.cpp".
Compilation terminated.

Note that our default gcc is 4.1.2 but we have gcc 4.7.1 located in a non std location that can be enabled by adjusting $path.

icc (Intel’s compiler) adjusts its behavior to $path… pgc++ does not.

any help would be appreciated.
[/code]

Hi Sylvain,

Because we use configuration, “rc”, files instead of environment variables to set which GNU version to use, you’ll need to create a new rc configured for use wiht GNU 4.7.1.

To do so, use the “makelocalrc” script found in the “bin” directory of your PGI install. Pass it the g++ and gcc compiler to use. For example:

% /opt/pgi/linux86-64/14.7/bin/makelocalrc /opt/pgi/linux86-64/14.7/bin -x -o -gpp /opt/gcc-4.7.1/bin/g++ -gcc /opt/gcc-4.7.1/bin/gcc > ~/.mypgcpprc

Please adjust paths as needed.

The “-o” flag says to direct the output to stdout, which I then redirect to a “.mypgcpprc” file in my home directory. This ensures that the changes are only applied to my pgc++ compiles. The caveat being if you use the compilers on another system, this rc file will still be applied.

You could also change the PGI install’s “localrc” by removing the “-o” and not redirecting the output. However, this would be applied to everyone using the compilers. Using “localrc.”, sets the configuration for all compiles on a particular host.

Hope this helps,
Mat

Hi Mat,

I’m back trying to use --c++11, and I found problems with makelocalrc and your instructions

I’m trying w/ gcc 4.9.2 and pgi 15.1 and a trivial test-array.cpp

1- in makelocalrc the line

if test ! -d "$outputdir "; then
echo “ERROR: output directory $outputdir not found”

there is an extra space in the ‘if test …’ before the closing ", so the test will always fails

2- the line

echo $GLIBC_VERSION > $base/glibc_version

require root privileges, but I’d like to do mods on a per user basis only

3- I had to comment out

      rm -rf $base/lib/libnuma.*
      ln -s $usrlib/libnuma.so.1 $base/lib/libnuma.so

to run as non-root

4- Now I can run it and

set GPPDIR32= and set GCCINC32= in the output file has err messages:

set GPPDIR32= … /usr/include In file included from /usr/include/features.h:385:0, from /usr/include/stdio.h:28, /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include <gnu/stubs-32.h>;

set GCCINC32= … /usr/include In file included from /usr/include/features.h:385:0, from /usr/include/stdio.h:28, /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include <gnu/stubs-32.h>;


So I was able to run a hacked makelocalrc

set gcc = gcc/4.9.2
set GCC = /share/apps/tools/$gcc/bin
set PGI = /share/apps/pgi
set pgi = 15.1

module load $gcc

./makelocalrc $PGI/linux86-64/$pgi
-x -o -d $cwd
-gpp $GCC/g++
-gcc $GCC/gcc > ~/.mypgcpprc

module unload gcc
unset gcc pgi

and now trying to compile a trivial test-array.cpp, I get:

module load pgi
make
/share/apps/pgi/linux86-64/15.1/bin/pgcpp --c++11 --gnu --gnu_extensions    test-array.cpp   -o test-array
"/share/apps/tools/gcc/4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/bits/alloc_traits.h", line 248: error: 
          expected a ">"
          = typename __construct_helper<_Tp, _Args...>::type;
                                                  ^
          detected during instantiation of type
                    "std::allocator_traits<_Alloc>::__has_construct<_Tp,
                    _Args...>" at line 251
....

I can send you the ~/.mypgcpprc I got, the hacked makelocalrc, test-array.cpp
and the full output of make. I can build and run test-array.cpp w/ gcc 4.9.2

Sylvain.

Thanks Sylvain. Please do send it to PGI Customer Service (trs@pgroup.com).

Makelocalrc does more than create a localrc file compatible
with gcc. It alters the installation by movinging compatible
header files and libraries into the PGI directories.

g++ 4.9 is not fully compatible with 15.1. I would recommend 15.3
or the current 15.4

If you wish to support more than one gcc version, here is what you do.

  1. download and install 15.4 release as a ‘Network’ installation.
    This will make sure the header and library files for a second gcc
    version are present.
    You will be asked for a commonly named local directory. This should
    be a path that is local to the platform, and therefore a different
    directory on every platform. /home/local/15.4/shared_objects, for
    example.

  2. Once the network installation is done on the machine named ‘foo’,
    you will see $PGI/linux86-64/15.4/bin/localrc.foo
    You will want to save localrc.foo, because you will remove it
    and replace it with a new one that you create.
    If you have a second host ‘bar’, and wish to make the PGI
    installation also work on bar
    ($PGI is a commonly mounted directory with the same pathname
    on bar.)
    just put $PGI/linux86-64/15.4/bin in your $PATH, and run
    “add_network_host” and you will see
    $PGI/linux86-64/15.4/bin/localrc.bar created, so bar can run
    run the compilers (if licensed).

  3. Back to creating localrc.foo for a new gcc version.
    Run the command
    % makelocalrc -x $PGI/linux86-64/15.4 -gcc /path/to/new/gcc-version/gcc
    -gpp /path/to/new/g+±version/g++ -g77 /path/to/new/gfortran-version/gfortran -net /home/local/15.4/shared_objects

Now you will have a new localrc.foo in the $PGI bin directory. When you want to use the old localrc.foo replace the new one.

You may also want everyone else to use the old localrc.foo,
and select users use the new localrc.foo. In that case, store the
new localrc.foo in your home directory as ~/siterc.foo.

You can verify ~/siterc.foo is read with
% pgfortran -dryrun x.f
! x.f need not exist
and you can see the rc files being read. Since siterc.foo is read after
the localrc.foo, the new information is applied to the driver actions.


We are in the process of cleaning this up a bit, but for now, this should work.

dave