PGI unsupported on macOS

[Paul Hargrove]

Testing on macOS Mojave (with Xcode 10 installed) shows the PGI support recently added for Linux does not extend to macOS. I am attaching output for possible reference.

I see very little motivation for targeting this compiler at this time.

[Paul Hargrove]

Document PGI as a supported compiler family

This adds PGI on Linux (19.1 on x86_64, 18.10 Linux/ppc64el) to the lists of supported compilers, and promotes these to "GOOD" in utils/system-checks.sh. Meanwhile, older versions on Linux are now BAD.

PGI on macOS is "BAD" (see issue #249).

Resolves issue #166

→ <<cset 2997df38bacf>>

[Paul Hargrove]

Automated closure on "cset 2997df38bacf" was erroneous.

reopening

[Paul Hargrove]

Retesting on the same macOS Mojave system with PGI 19.10 (Community Edition) I see a new failure mode:

/opt/pgi/osx86-64/19.10/bin/pgc++   -D_GNU_SOURCE=1 -DGASNET_SEQ     -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet
-stable -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/smp-conduit -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/other   -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/extended-ref/vis -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/extended-ref/coll -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/extended-ref/ratomic -I/Users/phargrov/upcxx/BLD-pgi1910/bld/GASNet-stable/extended-ref -I/Users/phargrov/upcxx/BLD-pgi1910/bld/gasnet.opt   -O2   -w -Masmkeyword -Msignextend -Mllalign    -std=c++11 --diag_suppress1427 -DUPCXX_ASSERT_ENABLED=0 -DUPCXX_BACKEND=1 -DUPCXX_MPSC_QUEUE_ATOMIC=1 -DUPCXX_BACKEND_GASNET_SEQ=1 -I/Users/phargrov/upcxx/BLD-pgi1910/bld/upcxx.assert0.optlev3.dbgsym0.gasnet_seq.smp/include -I/Users/phargrov/upcxx/BLD-pgi1910/bld/upcxx.assert0.optlev3.dbgsym0.gasnet_seq.smp/gen_include  -c /Users/phargrov/upcxx/src/backend/gasnet/noise_log.cpp -o noise_log.o
"/Users/phargrov/upcxx/BLD-pgi1910/bld/upcxx.assert0.optlev3.dbgsym0.gasnet_seq
          .smp/include/upcxx/backend/gasnet/runtime_internal.hpp", line 51:
          error: namespace "std" has no member "_pit_uintptr_t"
      cb->handle = reinterpret_cast<std::uintptr_t>(h);
                                         ^

1 error detected in the compilation of "/Users/phargrov/upcxx/src/backend/gasnet/noise_log.cpp".

This is interesting because _pit_uintptr_t (not in std::) is a C typedef in the GASNet headers.
So, this is probably a "silly" PGI error (conflating different typedefs with the same underlying type?).
This might even be possible to work around (by reordering some #includes?)
It may also be fixed in the next Community Edition release of macOS.

FWIW: I still don't think this platform is of great importance.

[Dan Bonachea]

This is interesting because _pit_uintptr_t (not in std::) is a C typedef in the GASNet headers. So, this is probably a "silly" PGI error (conflating different typedefs with the same underlying type?).

No, this is almost certainly caused by portable_inttypes.h:208:

#elif SIZEOF_VOID_P == SIZEOF_LONG
  typedef          long  _pit_intptr_t;
  typedef unsigned long _pit_uintptr_t;
...
 #define uintptr_t _pit_uintptr_t

This file is designed for use in C code and does not play nicely with C++ std:: inttypes. That define should probably be bracketed by !(__cplusplus)

However this brokenness is hidden on all modern platforms where COMPLETE_INTTYPES_H and/or COMPLETE_STDINT_H should be set in gasnet_config.h (which should precede the include of this file).

[Dan Bonachea]

Try this patch:

--- a/other/portable_inttypes.h
+++ b/other/portable_inttypes.h
@@ -36,6 +36,8 @@
     #include <stdint.h>
   #elif defined(COMPLETE_SYS_TYPES_H)
     #include <sys/types.h>
+  #elif __cplusplus >= 201103 && !defined(BROKEN_CSTDINT)
+    #include <cstdint>
   /* next, certain known systems are handled specially */
   #elif defined(_WIN32) && defined(_MSC_VER) /* MS Visual C++ */
     typedef signed __int8      int8_t;

[Paul Hargrove]

No, this is almost certainly caused by portable_inttypes.h:208:

Well, I am glad to be wrong.
This sounds like something that can (and should!) be fixed or worked-around.

Still not planning to spend significant time on this platform.

[Dan Bonachea]

Full proposed fix for portable_inttypes issue in GASNet PR 333

[Paul Hargrove]

So, the initial patch gets past the initial error, but now I have a 20,500-line log file full of template instantiation failure messages.
I have yet to try GASNet PR 333.

As observed via Slack, gasnet.opt/gasnet_config.h has a suspicious lack of definitions for COMPLETE_{INTTYPES,STDINT}_H.
I've not looked yet at config.log to sort out what went wrong, but I suspect a bad PGI install at the moment.

UPDATE: This compiler (reinstalled today) is badly broken at -O2. Even the following SEGVs w/ pgcc: int main(void) { return 0; } However, with -g I am still seeing tons of template instantiation failures indicating this compiler is NOT ready to support.

[Paul Hargrove]

As of the 20.1 PGI compiler release (Feb, 2020), this compiler family no longer supports macOS. So, I am resolving this issue as "wontfix".