Weakness in enforcement of icpc/g++ requirement

[Paul Hargrove]

Today Dan brought the following portion of utils/system-checks.sh to my attention:

        elif test -n "$CRAY_PRGENVINTEL" &&
             g++ --version | head -1 | egrep ' +\([^\)]+\) +([1-5]\.|6\.[0-3])' 2>&1 > /dev/null ; then
            echo 'ERROR: UPC++ on Cray XC with PrgEnv-intel requires g++ version 6.4 or newer in \$PATH. Please do: `module load gcc`, or otherwise ensure a new-enough `g++` is available.'
            exit 1

One significant defect worth noting is that this check is applied only to PrgEnv-intel on a Cray. However, the same floor exists on any system with Intel compilers.

The second, more subtle/insidious, defect is the assumption that g++ in ones $PATH is the right thing to query. However, there are at least three ways by which the user or sysadmin may provide a different g++ via a -gxx-name=... option.

• Explicit option in CXX or CXXFLAGS.
• Compiler configuration file (system or user-provided)
• __INTEL_PRE_CFLAGS environment variable

Dan and I agree we can perform a reliable query via preprocessor and the __GNUC__ and __GNUC_MINOR__ values. Implementing this query is "PART 1", and should be applied to all uses of the Intel compiler, not just the Cray PrgEnv-intel case.

There is also a third defect, which is that the probe is only performed at configure time and nothing is done to ensure the same g++ (and its libstdc++) are used when upcxx is run. This can (and so should) be addressed by adding an explicit -gxx-name=... to the value of CXX or CXXFLAGS (unless already present) to record the g++ which provided for the PASS in the query mentioned above. Of course the same needs to be done for -gcc-name in CC or CFLAGS. The details of how to do this correctly in light of the many ways that a g++ might be specified have been outlined elsewhere, but I am not transcribing them here.

Implementing the automated -gxx-name=... is "PART 2".

[Paul Hargrove]

pull request 196 attempts to address "PART 1"

[Paul Hargrove]

configure: address remainder of issue 347

This commit resolves issue 347 by adding logic (run at configure time) in platform_sanity_checks() to probe the (actual or effective) -gxx-name=... and -gcc-name=... options/settings of CXX and CC, respectively. These options are then appended to CXXFLAGS or CFLAGS as appropriate (unless already present). This ensures the same libstdc++ and libgcc (among others) will be used/linked by upcxx and users of our flags as reported by upcxx-meta even if the environment ($PATH in particular) differs from that probed at configure time.

→ <<cset 2fcc22af70e1>>

[Paul Hargrove]

configure: further improve icpc/libstdc++ handling

This commit makes the following improvements to the work introduced in pull request 196 (to resolve issue 347).

• Always add both -gxx-name and -gcc-name to CXXFLAGS to ensure correct behavior without assuming the need for -gcc-name is exclusive to Cray systems.
• Adjust warnings and error messages previously controlled by PRGEVNINTEL to instead check for /opt/cray as a way to identify systems we believe should always have supported intel and gcc environment modules.
• Adjust logic for the behavior to allow for older Intel compilers which have been seen to "zero out" minor and/or patch information when reporting the __GNUC*__ of the system compilers. We now allow such a case with just a warning, provided the major numbers match.

→ <<cset d2452233008e>>