20639, "stonea", "Erroring in gpu fork of compilation does not result in us returning a non-zero error code for chpl", "2022-09-06T23:12:41Z"
Erroring in gpu fork of compilation does not result in us returning a non-zero error code for chpl.
This is especially annoying because it means with our test infrastructure if we have a test that's locking down a compiler error and we produce a different error instead: instead of getting a nice diff of the .good file against the mismatching error start_test will think we succeeded and then error out when it can't find the executable (giving us "Error could not locate executable" instead).
This happened on one of our nightly runs of with the assertOnFailToGpuize.chpl test under the gasnet configuration (where at the time we were giving a different error message than we expected).
I find this confusing since I would have thought that this line here (which passes along a non-zero return code from the GPU fork) would have done just that:
But alas it doesn't.
You can repro this by doing the following:
use GPU;
extern proc foo() : void;
on here.gpus[0] {
foreach i in 0..10 {
assertOnGpu();
foo();
}
}
> chpl foo.chpl
warning: The prototype GPU support implies --no-checks. This may impact debuggability. To suppress this warning, compile with --no-checks explicitly
foo.chpl:1: In module 'foo':
foo.chpl:2: error: Could not find C function for foo; perhaps it is missing or is a macro?
> echo $?
0
Note the zero return status even though we errored out.
This example might stop working if we change how we handle GPUizing extern functions (you'll have to find something else that will cause an error to occur in the GPU codegen fork).