pgc++ 17.10 has trouble with glibc 2.26

Hi there,

compiling this trivial C++ example code …

#include <math.h>
#include <iostream>

int main(){
    std::cout << "pi in the sky ... " << M_PI << std::endl;
    return 0;
}

… with pgc++ 17.10 on Ubuntu 17.10 (which has glibc 2.26), I get:

"/usr/include/x86_64-linux-gnu/bits/floatn.h", line 62: error: invalid argument
          to attribute "__mode__"
  typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
                                                               ^

"/usr/include/x86_64-linux-gnu/bits/iscanonical.h", line 51: error: function
          "iscanonical(long double)" has already been defined
  inline int iscanonical (_Float128 __val) { return __iscanonicalf128 (__val); }
             ^

"/usr/include/math.h", line 505: error: function "issignaling(long double)" has
          already been defined
  inline int issignaling (_Float128 __val) { return __issignalingf128 (__val); }
             ^

On Ubuntu 16.04 (glibc 2.23) everything works well. Does that mean that pgc++ is incompatible with glibc 2.26? In particular it seems that the new quad-precision functions (_float128) make trouble. Any known workarounds?

Cheers,
Janus

Just found one myself:

#define __CUDACC__
#include <math.h>

Works due to this logic in bits/floatn.h:

/* Defined to 1 if the current compiler invocation provides a
   floating-point type with the IEEE 754 binary128 format, and this
   glibc includes corresponding *f128 interfaces for it.  The required
   libgcc support was added some time after the basic compiler
   support, for x86_64 and x86.  */
#if (defined __x86_64__							\
     ? __GNUC_PREREQ (4, 3)						\
     : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4))) \
     &&  !defined(__CUDACC__)
# define __HAVE_FLOAT128 1
#else
# define __HAVE_FLOAT128 0
#endif

Cheers,
Janus

Known limitation.

According to the PGI 17.10 release notes, under “Supported Platforms”, note that Ubuntu 16.10 is the newest Ubuntu we support, and gcc 6.3 is the newest gcc.

We will probably get 7.2 working with 18.1, and so the Community Edition will support it in 18.4.

So wait for 2 to 6 months, or install a Linux version we support.

dave

Well, https://www.pgroup.com/resources/docs/17.10/x86/pgi-release-notes/index.htm only says “Ubuntu 12.04+, including Ubuntu 16.10”

I read that 16.10 works, but no warning that later versions do not work. It would be great if you could make this more explicit, otherwise I’m sure you will keep getting tons of error reports.

Even slightly worse, https://www.pgroup.com/products/index.htm?tab=specs#reqs only says “Ubuntu 12.04 or newer”.


So wait for 2 to 6 months, or install a Linux version we support.

Nope, I’ll rather use a compiler that suits my needs and works on more recent operating systems. gfortran does it perfectly.

Cheers,
Janus

It’s usually not the Linux version, but the gcc version that
makes a Linux version incompatible with PGI compilers.

But if gfortran suits your needs, we are glad you have the tools
you need now.


dave

please see my post ‘invalid argument to attribute’ …

PGI-17.10 is not compatible to GCC’s attribute.
PGI doesn’t understand the parameter ‘mode’.

the typedef:
typedef _Complex float __cfloat128 attribute ((mode (TC)));

Can be compiled with GCC-4.9.2 (tested) - so it is an issue of PGI’s incompatiblity to GCC-4.9.x (and probably older).

Hi,

I’m using ubuntu 18.04 and PGI Community Edition 18.4, and I have the same problem described in the opening post.
I tried the suggested solution from janus (define + include), but unfortunately it is not working for me.
Also, I tried to switch to g++ versions 5, 6 and 7, but none of them compiles the source code for me (as far as I know the pgc++ uses the g++ provided by the OS, but correct me if I’m wrong).
I searched the PGI website to find something about the limitation mentioned by jtull, but I didn’t find anything about it (I mean whether it has been resolved already or not).
Do we have any information/update regarding this problem?

Thanks!
Joseph

Hi Joseph,

The list of supported Linux OS versions can be found in the PGI 18.4 release notes: https://www.pgroup.com/resources/docs/18.4/x86/pgi-release-notes/index.htm#supported-opsys-updates

Unfortunately, Ubuntu 18.04 is too new for us to support it. It looks like both actually came out on the same day (April 26th, 2018) and it usually takes a us a few releases to get a new OS supported.

Though, I did just try installing 18.4 on a Ubuntu 18.04 system and it seemed to work fine. Did you install GNU 8? If so, then this would be the cause of the error.

Also, I tried to switch to g++ versions 5, 6 and 7, but none of them compiles the source code for me (as far as I know the pgc++ uses the g++ provided by the OS, but correct me if I’m wrong).

What do mean by switching version? It’s not enough to switch what version of GNU is in your PATH environment. Instead you need to generate a PGI config file (called “localrc”) to a compatible GNU version (like 7.2 or 7.3)

To create a localrc file, run the following command but change the GNU paths for your system:

makelocalrc -x -d . -gcc /home/thirdparty/gcc/gcc-7.2.0/bin/gcc -gpp /home/thirdparty/gcc/gcc-7.2.0/bin/g++ -g77 /home/thirdparty/gcc/gcc-7.2.0/bin/gfortran

This will create a “localrc” file in your local directory. Copy this file to your PGI install’s bin directory to override the current configuration. Alternately, you can copy it under a different name, such as “localrc.720”, and then set the environment variable “PGI_LOCALRC=/path/to/pgi/bin/localrc.720” so the compilers will use this configuration.

Hope this helps,
Mat

Hi Mat,

thank you for the detailed description!

By switching to different g++ versions I mean using the “sudo update-alternatives --config g++” bash command then selecting one from the list. I guess this is an “official” way to choose a particular g++ version if you have more than one installed.

Nevertheless, I tried your “makelocalrc” suggestion. Unfortunately, it gives a permission denied error:

/opt/pgi/linux86-64/18.4/bin/makelocalrc: line: 758: /opt/pgi/linux86-64/18.4/glibc_version: Permission denied

I tried with sudo, but since I intalled the PGI only for my account the command makelocalrc is obviously not found in the root shell.
I will try to install the PGI into my $HOME directory, maybe in that case it’ll work. If it won’t then I will install an earlier version of ubuntu which has already been tested with PGI 18.4.

Thanks again, I appreciate your help!

Joseph

Hi Joseph,

/opt/pgi/linux86-64/18.4/bin/makelocalrc: line: 758: /opt/pgi/linux86-64/18.4/glibc_version: Permission denied

Can you give yourself write permissions to the 18.4 directory?


-Mat

Hi Mat,

sorry for the late reply.
I made the PGI dir writable, but I still got the same error.
So, I decided to install the 16.04 ubuntu, then the CUDA toolkit and
driver from the nvidia website.
It didn’t work either, so I tried the toolkit and driver from the
official ubuntu reporsitories and it works fine now.
Anyway, thank you for the help!

Joseph

Hello Mat,

we have a very similar problem on our end.

[…]/boost/type_t
raits/is_floating_point.hpp", line 25: error: class
“boost::is_floating_point” has already been defined
template<> struct is_floating_point<__float128> : public true_type{};
“/usr/lib/gcc/x86_64-linux-gnu/6/include/quadmath.h”, line 32: error: 128-bit
floating-point types are not supported in this configuration
typedef _Complex float attribute((mode(TC))) __complex128;

This error appears on a Debian-9 system with gcc 6.3.0, pgi 18.4 and glibc 2.24 and boost 1.63.0.

Do you have any idea which might be the critical tool that causes the incompatibility?

Thanks a lot for any answer you can offer.

Cheers,
Jan

Hi Jan,

We don’t support quad precision. I’m not sure how you have Boost configured but don’t define “BOOST_HAS_FLOAT128” and then you should be able to work around this issue.

-Mat

Hi,

I came across this same problem with my Linux Mint 19 install (which uses Ubuntu 18.04 underneath).

The compiler (18.7) was working but when I tried to compile HDF5 it crashed with the redundant math.h errors.

After reading this thread, I simply edited the rclocal file and replaced all the “5s” with “7s” (my machine uses GNU 7 by default). I also updated the GNU version number in that file.

After that, HDF5 compiled! (I did have to use the “export CPP=cpp” trick as mentioned in another thread).

I tested it on our code that links to HDF5 and it works!

Hope this helps.

  • Ron