builtin_launder is wrong for cross-compilation

[Dan Bonachea]

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

[Paul Hargrove]

I'll work on this later today

[Dan Bonachea]

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);
}

[Amir Kamil]

I did not observe any runtime failures of this test other than Intel.

[Paul Hargrove]

I find our floor versions of g++ (6.4.0), clang++ (4.0.0) and pgc++ (19.1) all fail this probe on Dirac.

[Amir Kamil]

@Paul Hargrove Do they fail when compiling the code or running it?

[Paul Hargrove]

@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.

[Amir Kamil]

Fixed via PR 383.