- changed status to open
builtin_launder is wrong for cross-compilation
I just happened to notice that the utils/config/upcxx/builtin_launder.sh
post-configure probe is building AND running a test on the build system, without a fallback for cross-compilation.
IIUC this means the test may spuriously fail on cross-compiled Cray XC systems using non-Intel compilers.
This probe should be converted to perform compile-time detection of the known-broken Intel compiler via #error
and conservatively assume success for other compilers when UPCXX_CROSS
Comments (8)
-
-
-
assigned issue to
-
assigned issue to
-
reporter Note this code was added by Amir AFTER the last release, in response to issue 481.
@Amir Kamil are you aware of any non-Intel compilers that were failing the runtime component of this test?
@Paul Hargrove we should probably survey the generated upcxx_config.h files across (non-cross-compile) builds to determine if this test detected any failures at runtime.
#include <new> struct A { int x; }; struct B { const int z; B() : z(-1) {} }; int main() { B b; const int i = b.z; A *a = ::new(&b) A; a->x = 3; const int j = __builtin_launder(reinterpret_cast<A*>(&b))->x; #if __INTEL_COMPILER // Intel compiler does not appear to properly support __builtin_launder // see issue 481 and PR 358 for details return 1; #endif return !(i == -1 && j == 3); }
-
I did not observe any runtime failures of this test other than Intel.
-
I find our floor versions of g++ (6.4.0), clang++ (4.0.0) and pgc++ (19.1) all fail this probe on Dirac.
-
@Paul Hargrove Do they fail when compiling the code or running it?
-
@Amir Kamil Right, good point.
I've confirmed that these three failure occur at compile time complaining that
__builtin_launder
is not defined, and thus this is correct probe behavior.
Sorry for the false alarm. -
- changed status to resolved
Fixed via PR 383.
- Log in to comment
I'll work on this later today