long double datasize issues for shmem_put_global tests

[naveen-rn]

@tonycurtis The datasize for long double is assumed as 128b on the feature_tests/C/test_shmem_put_globals.c tests. It seems the long double datasize depends on the compiler precision. It can vary from 64b to 128b. Using long double variables for testing shmem_put128 doesn't seem right.

Let me know what you think.

[tonycurtis]

On Mar 14, 2017, at 6:47 PM, Naveen Ravi ***@***.***> wrote: @tonycurtis <https://github.com/tonycurtis> The datasize for long double is generalized as 128b on the feature_tests/C/test_shmem_put_globals.c tests. The long double datasize depends on the compiler. It can vary from 64b to 128b. Using long double variables for testing shmem_put128 doesn't seem right. Let me know what you think.

want to replace them with malloc()ed buffers? tony

[jdinan]

One fix would be to adjust the array length:

long double src4[N*128/sizeof(long double)];

But this messes up indexing elsewhere and is fragile if long double is ever larger than 128B..

My preference would be to use the sized integers when testing any of the SHMEM routines that contain a number of bytes/bits in the function name. Or, for a more minimal change, to add an error check that the size of the type meets the requirements of the unit test.

[naveen-rn]

int16_t foo[8][N]; shmem_put128(foo, foo, N, 1);

Can we do something similar to the above example. It looks like a possible usage for shmem_put128 in a global variable on real applications.

[naveen-rn]

@tonycurtis Shall i create a PR for this change?

[tonycurtis]

On Mar 20, 2017, at 2:09 PM, Naveen Ravi ***@***.***> wrote: @tonycurtis <https://github.com/tonycurtis> Shall i create a PR for this change?

Sure. tony