NAG fixes.

[DJDavies2]

Resolves #212. There are three types of change:

Addition of target attribute to some variables (see e.g. ecmwf/fckit#43)

In array_c_to_f (in atlas_Field_module.fypp) the call to c_f_pointer is sometimes passing a shape where one of the bounds is 0. This results in tmp being null, meaning that subsequent array slices being pointed at by array_fptr are invalid. I have addressed this by allocated a 0 size array.

atlas_fctest_field_wrap was failing like this:

/spice/scratch/frwd/cylc-run/mi-be984/work/1/git_clone_atlas/atlas/src/tests/field/fctest_field_wrap.F90:116: warning: FCTEST_CHECK_EQUAL(data(i,j,l) , real(1000i+100j+10*k+l,c_double) )
--> [ 1.1210000000000000E+03 != 1.1120000000000000E+03 ]

I tracked this down to the function array_strides which was returning the wrong values, resulting ultimately in the arrays being compared in the test being out of sync with each other. The difference between NAG and other compilers appears to be that NAG is pass the argument to array_strides via copy-in/copy-out; this can be verified by printing pointer values. This collapses the strides so that the array_strides calculation is incorrect.

I don't think array_strides can be fixed; what it is trying to do is unportable because passing arguments via copy-in/copy-out or by reference (or any other mechanism) is allowed. There is never any guarantee that this will give the right answer. The change here replaces the array_strides call with an inline implementation for the particular case that fails, but of course array_strides is used in many other situations (including outside of atlas) and I haven't touched those.

I really think that array_strides should be looked at again and rethought. As it stands it isn't just a portability issue across compilers, but also in the future as well; updated versions of compilers that currently work can start to fail this due to changes of implementation.

[wdeconinck]

Is there no issue with rank == 2 ? Perhaps not in what gets tested...

[DJDavies2]

It doesn't show up in a test. However it could just be that this isn't tested either in fckit or atlas.

[wdeconinck]

I extended this now with rank == {1,2,4} as well, to be sure.

[wdeconinck]

Thanks once more in progressing with NAG.

Bullet 3. seems indeed to be quite problematic and not really a satisfactory solution...

If NAG is using copy-in (pass-by-value?) of 'data' instead of pass-by-reference, is that not detrimental for large arrays, or is there some introspection going on... ¯_(ツ)_/¯

Is there a means to force pass-by-reference in fckit's array_strides ?
Could you isolate a test in fckit (if you have time) to demonstrate the problem there as well, and perhaps a workaround for array_strides... If we were to review array_strides, is there a way to force arguments to be passed by reference instead of copy-in/copy-out?

[wdeconinck]

Approving and merging already, but please consider above comments @DJDavies2