RFE: stronger configure checks on CXX
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.
Comments (7)
-
-
reporter 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.
-
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. -
reporter - changed status to open
I am working on this.
Below are partial results from an initial proof-of-concept, tested with
configure CC=icc
and withconfigure CC=pgcc
, each of which experience has show will fail with the sameundefined 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
-
reporter It is worth noting that currently the failure mode for
configure CC=icc; make check
is not theundefined reference
errors (a "library ABI" difference) but instead an error which I beleive is the result from passing GASNet's probedCFLAGS
toCXX
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).
-
reporter - changed milestone to 2022.3.0 release
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. -
reporter - changed status to resolved
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.
- Log in to comment
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.