> On May 22, 2019, at 11:27 AM, Jed Brown <[email protected]> wrote:
>
> Agreed, though need to test that all relevant compilers error
> appropriately (and that we accurately detect such errors). Satish may
> remember which are most problematic.
>
> There are a few other --known arguments that we may need to think about.
> I think these are tough:
>
> --known-snrm2-returns-double=0
> --known-sdot-returns-double=0
These should only be tested when running with single precision so won't
effect most people.
>
>
> Byte swapping to/from big endian for integer types can be written in a
> portable way that compiles to no-op (at least when optimization is on;
> but see [1]), but I don't think that's possible for floating point data.
> Of course we could just compile code for both options and select which
> one to call at run-time. Since they operate on arrays instead of
> individual values, the dispatch should be negligible.
This is a great idea, we should do it. Presumably we just run the test to
determine which format the system uses once, the first time we need to byte
swap and then reuse the info?
This is great, we should keep the batch infra structure in BuildSystem in
place but if we don't need to use it most of the time that will be a really
nice feature.
Satish, can any of these new ideas be propagated through the xSDK
community so that other packages can eliminate their need for running programs
during ./configure (like hypre) and make xSDK builds on the DOE sites much less
painful?
Thanks everyone for these ideas!
Barry
>
> [1] It's sometimes buggy. https://bugs.llvm.org/show_bug.cgi?id=41545
>
> "Smith, Barry F. via petsc-dev" <[email protected]> writes:
>
>> It would be fantastic if we could avoid the need for the known values and
>> ideally the need for batch completely!!!!
>>
>> This is a great idea.
>>
>>> On May 22, 2019, at 5:02 AM, Lisandro Dalcin via petsc-dev
>>> <[email protected]> wrote:
>>>
>>> Barry/Satish, you know that making requests without patches is not my
>>> style, but this one involves messing with BuildSystem, so please pardon me.
>>>
>>> I have a easy and quick proposal for compile-time determination of sizeof()
>>> for the various C types. For example, in our Cray XC40, I'm passing all
>>> these flags to configure to avoid the need of running with batch:
>>>
>>> $ grep known-sizeof reconfigure-arch-gnu-opt.py
>>> '--known-sizeof-MPI_Comm=4',
>>> '--known-sizeof-MPI_Fint=4',
>>> '--known-sizeof-char=1',
>>> '--known-sizeof-double=8',
>>> '--known-sizeof-float=4',
>>> '--known-sizeof-int=4',
>>> '--known-sizeof-long-long=8',
>>> '--known-sizeof-long=8',
>>> '--known-sizeof-short=2',
>>> '--known-sizeof-size_t=8',
>>> '--known-sizeof-void-p=8',
>>>
>>>
>>> Look at the following two line C source, TYPE and SIZE have to be passed
>>> through the preprocessor in this quick example. Defining main is of course
>>> not required if we pass `-c` to the compiler.
>>>
>>> $ cat check-sizeof.c
>>> typedef char assert_sizeof[(sizeof(TYPE)==SIZE)*2-1];
>>> int main(int arg, char *argv[]) { return 0;}
>>>
>>> Let's try to determine sizeof(double) by compile-time checks that do not
>>> need to run the executable.
>>>
>>> $ cc -DTYPE=double -DSIZE=1 check-sizeof.c
>>> check-sizeof.c:1:14: error: size of array ‘assert_sizeof’ is negative
>>> 1 | typedef char assert_sizeof[(sizeof(TYPE)==SIZE)*2-1];
>>> | ^~~~~~~~~~~~~
>>>
>>> $ cc -DTYPE=double -DSIZE=2 check-sizeof.c
>>> check-sizeof.c:1:14: error: size of array ‘assert_sizeof’ is negative
>>> 1 | typedef char assert_sizeof[(sizeof(TYPE)==SIZE)*2-1];
>>> | ^~~~~~~~~~~~~
>>>
>>> $ cc -DTYPE=double -DSIZE=4 check-sizeof.c
>>> check-sizeof.c:1:14: error: size of array ‘assert_sizeof’ is negative
>>> 1 | typedef char assert_sizeof[(sizeof(TYPE)==SIZE)*2-1];
>>> | ^~~~~~~~~~~~~
>>>
>>> Up to here, sizeof(double) is not 1, nor 2, nor 4.
>>>
>>> Let's try now if sizeof(double) is 8:
>>>
>>> $ cc -DTYPE=double -DSIZE=8 check-sizeof.c
>>>
>>> No compile error. Success! Now we know sizeof(double) is 8, we don't need
>>> to run an executable, which is ideal for cross-compiling or to avoid
>>> running the configure test with batch.
>>>
>>>
>>> --
>>> Lisandro Dalcin
>>> ============
>>> Research Scientist
>>> Extreme Computing Research Center (ECRC)
>>> King Abdullah University of Science and Technology (KAUST)
>>> http://ecrc.kaust.edu.sa/
