Improve documentation regarding "non-system" compilers

This is an off-shoot of discussion begun in issue 415.

On a Linux system, one can normally be confident that gcc/g++ "just work".
Similarly, on macOS one can count on Xcode's clang/clang++.
To almost the same degree one can expect that the defaults for each PrgEnv-* on a Cray XC will function reliably.
Package manager installs of llvm/clang on Linux and of GCC on macOS are also generally fairly trustworthy.

A common property of Intel and PGI compilers, and of llvm/clang installs on Linux, are that they are dependent on an existing GCC installation (for libstdc++ in particular), and the system headers (glibc's /usr/include). Once one begins mixing such compilers with GCC or glibc they were never developed/tested against, bad things may happen. One example (that motivated this issue) is evident in issue 415. However, we've seen others such as issue 290 and issue 302 in which a "too new" libstdc++ caused problems for PGI and Intel compilers, respectively.

One complication shown in issue 415 is that the system headers (glibc on Linux, and mostly independent of the GCC version) can contribute to the problem. In that specific case, use of fixed-width floating point types was enabled for __GNUC__ >= 7. So, pairs of GCC + CompilerFoo that work on one system (such as Dirac) may not work on another (such as Cori) due to a different glibc.

The purpose of this issue is to add some version of the text above to our in-repo documentation. The main rules of thumb are probably:

Read compiler's release notes for minimum required GCC and glibc
Look for any maximums (less likely) in those same release notes
Assume that any GCC or glibc release more recent than 90(?) days prior to the compiler's release data is to be avoided.

Comments (8)