RFE: stronger configure checks on CXX

[Paul Hargrove]

While discussing pull request 350, Dan and I observed that we currently perform fairly minimal checks for the "sanity" of the C++ compiler at configure time.

We currently parse the --version output to apply allow-list and ban-list logic.

However, we don't yet check that the C++ compiler "works" in the sense that it can compile and link anything. Nor do we check that it is link-compatible with the C compiler. While GASNet's configure script checks both of those things later (at UPC++ make all time), its response to failed checks is to disable UDP conduit (its only use of C++). So, a "useless" CXX setting may remain unnoticed until make check or a user's eventual application link time.

The purpose of the RFE is to request that utsil/system_checks:platform_sanity_checks() at least perform the level of checking described immediately above.

The minimal probe of CXX sanity requires just a "Hello, World!" test. Going forward, we could include additional tests of at least basic STL usage and/or key C++11 syntax.

[Dan Bonachea]

PR 360 addressed the bulk of this issue, but @Paul Hargrove is planning to expand the set of libraries probed to catch more ABI incompatibilities between compilers at configure time.

[Paul Hargrove]

As Dan mentions above, I am looking to (at least) add calls to the C half of the link-compatibility test that proxy for things GASNet does that we have reason to suspect (or know from experience) are turned into calls to a compiler-specific runtime library.

The main obstacle I face right now is that the behavior I am hoping to reproduce normally requires enabling optimization. However, this test is running long before GASNet has chosen the optimization flags that will be used in the final link.

[Dan Bonachea]

Copied from GASNet meeting notes:

We want the C test code to "proxy" for libgasnet invocations of the following representative C library symbols:

• memcpy, memset, strlen, strcpy, strcmp, fprintf, atoi, strtod, errno, va_{start.end,arg}

Where most ABI problems will result in a link failure.

As Paul mentions we might need some optimizations enabled to activate "problematic" library ABI incompatibilities. I suggest we compile the C object in the test with -O3, which is accepted by all our supported C++ compilers and is an "upper bound" on the optimizations libgasnet objects might use.

[Paul Hargrove]

I am working on this.

Below are partial results from an initial proof-of-concept, tested with configure CC=icc and with configure CC=pgcc, each of which experience has show will fail with the same undefined reference error at application link time.

{phargrov@pcp-d-6 B}$ cat config-detail.log
+ /usr/local/pkg/intel/oneapi/compiler/2021.1.2/linux/bin/intel64/icc -O3 -c conftest-cc.c
+ /usr/local/pkg/gcc/11.1.0/bin/g++ -c conftest-cxx.cpp
+ /usr/local/pkg/gcc/11.1.0/bin/g++ -o conftest.o conftest-cc.o conftest-cxx.o -lm
conftest-cc.o: In function `cfunc':
conftest-cc.c:(.text+0x1d4): undefined reference to `__intel_sse2_strlen'
conftest-cc.c:(.text+0x214): undefined reference to `__intel_sse2_strcpy'
conftest-cc.c:(.text+0x224): undefined reference to `_intel_fast_memcpy'
collect2: error: ld returned 1 exit status

{phargrov@pcp-d-6 B}$ cat config-detail.log
+ /usr/local/pkg/pgi/linux86-64/20.4/bin/pgcc -O3 -c conftest-cc.c
+ /usr/local/pkg/gcc/11.1.0/bin/g++ -c conftest-cxx.cpp
+ /usr/local/pkg/gcc/11.1.0/bin/g++ -o conftest.o conftest-cc.o conftest-cxx.o -lm
conftest-cc.o: In function `vsum':
/home/pagoda1/phargrov/upcxx/B/conftest-cc.c:14: undefined reference to `__builtin_va_gparg1'
/home/pagoda1/phargrov/upcxx/B/conftest-cc.c:14: undefined reference to `__builtin_va_gparg1'
/home/pagoda1/phargrov/upcxx/B/conftest-cc.c:14: undefined reference to `__builtin_va_gparg1'
collect2: error: ld returned 1 exit status

[Paul Hargrove]

It is worth noting that currently the failure mode for configure CC=icc; make check is not the undefined reference errors (a "library ABI" difference) but instead an error which I beleive is the result from passing GASNet's probed CFLAGS to CXX at link time:

+ env UPCXX_CODEMODE=debug UPCXX_THREADMODE=par UPCXX_NETWORK=ibv /home/pagoda1/phargrov/upcxx/B/bin/upcxx /home/pagoda1/phargrov/upcxx/test/uts/uts_hybrid.cpp -o test-uts_hybrid-ibv
g++: error: unrecognized command-line option `-wd177'
g++: error: unrecognized command-line option `-wd279'
g++: error: unrecognized command-line option `-wd1572'
Compiling test-uts_hybrid-ibv                                          FAILED

Building a GASNet-based C++ test via make gasnet DO_WHAT=testcxx fails in the same manner.
So, I believe our actual limitations on mixing compiler families includes command line compatibility in addition to the library compatibility this new probe is checking.

This observation makes me wonder if this work to strengthen the link check is worthwhile, if in practice we'd be better off (more representative of the final link result) by just comparing the families as GASNet's configure does (though only to warn in that case).

[Paul Hargrove]

This is no longer under consideration for the 2021.9.0 release. Rolling over to 2022.3.0.

To ensure the work is not lost, I am recording here that the work-in-progress mentioned in an earlier comment is in the branch issue474-part2 of my private fork.

[Paul Hargrove]

I believe that the combined contributions of pull request 360 and pull request 396 have effectively "plugged all the holes" which this issue was intended to address.