Support NVIDIA HPC SDK Compilers

[Paul Hargrove]

One result of the acquisition of Portland Group by NIVIDA is that the 20.7 compiler suite that would have been "PGI 20.7" is called "NVIDIA HPC SDK Version 20.7"

I find that when invoked by legacy names pgcc and pgc++ the pre-processor identification is backward compatible (looks like 20.7 PGI release).

When invoked as nvc and nvc++ these appear to be a new/different (and unknown to us) compiler family.

The purpose is to add compiler family identification (which might just mean expanding the identification of PGI to encompass this compiler's output).

Until work is done for this issue, simply use CC=pgcc CXX=pgc++ (or similar) when targeting this new compiler release.

[Paul Hargrove]

Proposed changes in pull request 253

[Paul Hargrove]

As noted in this forum posting, the 20.7 NVIDIA HPC SDK release changed the numbering of diagnostic messages, and for the 20.9 release it was decided to bless the new numbering as the canonical one for the new NVIDIA branding.

Because we rely on (at least) --diag_suppress1427 to control unwanted/unwarranted warnings this change in numbering may require extra effort on our part to make the suppression flag version dependent (potentially simply by classifying the NVIDIA-branded compilers as a distinct family?)

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Dan Bonachea]

It's been announced (slide 17) that the Cray-supported Perlmutter environment will include a PrgEnv-pgi (but not a PrgEnv-intel). This will presumably actually use a recent release of the NVIDIA-branded HPC SDK, which our configure script currently refuses.

Bug 4158 documents our current efforts testing with this compiler (which is still generating new failures as of the latest 20.11 release). Note this is orthogonal to issue #421 which affects all versions of PGI.

Upgrading this issue to release blocker to either add support for this (rebranded) compiler family, or perform enough triage to establish a sound technical basis for continuing to prohibit it.

[Dan Bonachea]

Mass roll-over of open issues to next release milestone

[Paul Hargrove]

Following a change in GASNet-EX's configure logic to use -O1 rather than -O2, we now have sufficient testing history with this compiler family to confidently support its use on x86_64 and ppc64le systems (aarch64 support is not yet as well tested).

Proposed updates to documentation and configure-time logic in pull request 369

[Paul Hargrove]

Resolved via merge of PR 369 at commit 435c67f3