Fortran configury: Ensure F08 real_kinds are actually valid kinds

[lrbison]

Closes #5090

[brtnfld]

For consistency, the same changes should be made to FC_AVAIL_KINDS.

[brtnfld]

please use uppercase keyword intrinsics

[lrbison]

Addressed.

[brtnfld]

I have to ensure this does not suppress detected kinds of other compilers since that scenario would not cause tests to fail.

[lrbison]

please use uppercase keyword intrinsics

Done!

I have to ensure this does not suppress detected kinds of other compilers since that scenario would not cause tests to fail.

Sure. In my testing I saw that GNU Fortran was unaffected. You can see output here.

For these next two points let me clarify that SELECTED_REAL_KIND is correct in ACfL, it is only the F08 ISO_FORTRAN_ENV array REAL_KINDS that was wrong. That array was only used to print the real kinds the compiler supported (not max precision), so I don't think the following comments items require a change:

If the KIND is not supported, then the maximum decimal precision, max_decimal_prec, should not be set for that KIND.

The REAL_KINDS array was not used in the loop to determine max decimal precision, so it is already correct.

For consistency, the same changes should be made to FC_AVAIL_KINDS.

The non-F08 version of this loop builds the list of kinds based on the return values of SELECTED_REAL_KIND, so it never had the problem.

... however it makes me wonder if the preferred fix is just to ignore REAL_KINDS altogether and use FC_AVAIL_KINDS's logic to find real kinds.

[brtnfld]

The non-F08 version of this loop builds the list of kinds based on the return values of SELECTED_REAL_KIND, so it never had the problem.

I'm not sure the compiler does not also have an issue with SELECTED_REAL_KIND, as from our discussion, #5090,

k = SELECTED_REAL_KIND(19,2)
print*,k
end

Printed -1, so it does not support KIND=16.

[lrbison]

Printed -1, so it does not support KIND=16.

Correct. ACfL does not support KIND=16, yet it includes 16 in REAL_KINDS (a compiler bug). This caused HDF5 configuration to make code with REAL(KIND=16) which then fails to compile. I am suggesting this patch to work around the compiler bug.

[lrbison]

@brtnfld so are there other changes you think are required?

[brtnfld]

num_rkinds gets its value from size(real_kinds), which is going to include KIND=16.
max_decimal_prec is going to be for KIND=16, and not KIND=8, or whatever the highest kind supported.

[lrbison]

@brtnfld Yes, num_rkinds will be size(real_kinds), but in the loop before we print the kinds we check the new logical array with IF(.NOT. found_rkinds(k)) CYCLE. I've also updated the logic to ensure we don't print trailing commas, double commas, or anything like that.

max_decimal_prec is going to be for KIND=16, and not KIND=8, or whatever the highest kind supported.

No. On line 216 k = SELECTED_REAL_KIND(ik,jk) never selects kind=16 in ACfL, therefore the max_precision remains correct. When ik goes above 15 selected_real_kind returns -1 and the existing logic exits the loop and max_decimal_prec is never updated further. This is also seen from the issue where I show the test output has -- ....MAX DECIMAL PRECISION 15 rather than 33 as it does in GFortran.

[brtnfld]

num_rkinds is printed later in the program, so it should reflect the number of real KINDS actually printed.

[lrbison]

num_rkinds is printed later

I see, I had missed that, thank you for pointing it out. Testing with cmake -S ../hdf5 -DCMAKE_Fortran_COMPILER=gfortran/armflang -DHDF5_BUILD_FORTRAN=ON: Gfortran cmake prints:

-- ....NUMBER OF INTEGER KINDS FOUND 5
-- ....REAL KINDS FOUND {4,8,16}
-- ....INTEGER KINDS FOUND {1,2,4,8,16}
-- ....MAX DECIMAL PRECISION 33
-- ....LOGICAL KINDS FOUND {1,2,4,8,16}
-- ....FOUND SIZEOF for REAL KINDs {4,8,16}

and ACfL prints

-- ....NUMBER OF INTEGER KINDS FOUND 4
-- ....REAL KINDS FOUND {4,8}
-- ....INTEGER KINDS FOUND {1,2,4,8}
-- ....MAX DECIMAL PRECISION 15
-- ....LOGICAL KINDS FOUND {1,2,4,8}
-- ....FOUND SIZEOF for REAL KINDs {4,8}

The test program itself prints:

gfortran ./test.f90 && ./a.out
1,2,4,8,16
4,8,16
33
5
3
5
1,2,4,8,16

armflang ./test.f90 && ./a.out
1,2,4,8
4,8
15
4
2
4
1,2,4,8

[lrbison]

@brtnfld fixed and rebased

[lrbison]

@brtnfld can you take another look?

[brtnfld]

LGTM, thanks for the fix.!