inlinining/ dispatch problem
This is related to issue #2278 in the sense that this bug triggered the observation of #2278.
We have a module UTThornBoolean.sac
which is used by UTThornBoolean.unittest.sac
.
This code is a unit test for code generated by the APEX compiler's SaC
array formatting functions, in this particular case operating on Boolean arrays.
(A similar failure to that presented here occurs with integer and double arrays.)
Executing
sac2c UTThornBoolean.sac
sac2c UTThornBoolean.unittest.sac
./a.out
yields the correct result:
Dimension: 1
Shape : < 5>
<0 1 0>
When using -DERROR on the first sac2c call, we erroneously obtain
Shape : <>
0
The problem seems related to the dispatch of the format function and the view of format within UTThornBoolean. The failure appears to be related to SaC modules, and is sensitive to code inlining. Specifically, -noinl (on the sac2c command line) or at function headers within the executed code), or execution outside of modules, changed the failure and/or allowed the code to run correctly.
BTW, fault isolation for these types of failures is protracted, due in part to the slow execution of the sac2c compiler on any non-trivial source code. If recompiling the Stblib is part of the fault-isolation show, this can be extremely frustrating for those of us with uncomfortable chairs.
The specific fault appears to lie in the wrapper functions generated by sac2c. The job of the wrapper functions is to dispatch (call) the proper version of a function, based on the characteristics of the function argument and its parameters. In this case, the argument to Stdlib's ArrayFormat::format( X) had an argument X of type "bool[3]", but the dispatched version of format() required an argument X of type "bool", a scalar.
Moving format() into the apex-generated code caused the unit test to work properly, because the dispatch code had been optimized away by sac2c. We have been unable to recreate the failure without using a call tree of the form:
main() --> localModule() --> StdlibModule::format()