PGI unsupported on macOS
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.
Comments (9)
-
reporter -
reporter - changed status to open
Automated closure on "cset 2997df38bacf" was erroneous.
reopening
-
reporter - changed title to PGI unsupported on macOS
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 instd::
) 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#include
s?)
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.
-
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).
-
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;
-
reporter 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.
-
Full proposed fix for portable_inttypes issue in GASNet PR 333
-
reporter 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 forCOMPLETE_{INTTYPES,STDINT}_H
.
I've not looked yet atconfig.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. -
reporter - changed status to wontfix
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".
- Log in to comment
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>>