Description
Motivation
I'm a little confused about the default in stdlib_kinds being to disable xdp and qp by setting those values to -1 unless the user explicitly asks for computation with qp during the preprocessing stage (unless I'm misunderstanding something and this is not the case). Is this what's happening ? If so, this disables the default computation of functions like gamma and log_gamma with complex(dp) arguments because they are expected to be calculated in qp.
Not having xdp and qp enabled as default for systems that do not support them is understandable. Although selected_real_kind() already handles this in sense by returning a value of -1 for unsupported kinds, trying to compile code with real(kind=-1) :: var will just produce an error, which is also not desirable.
Could there be a small (Fortran ?) program to run and determine which kinds are > 1 and which are == -1?
For example, if selected_real_kind(33) does not return -1, then we can set qp = selected_real_kind(33) in stdlib_kinds and ensure that qp is in the REAL_KINDS array before the preprocessing.
Maybe the user can then go ahead and explicitly disable xdp and qp kinds if they really want to, even though those kinds are supported by their system. This could probably be done by just changing the default value of WITH_QP in include/common.fypp after determining whether such a kind is supported (same goes for xdp), but maybe that's not a good approach.
This way, users can continue to seamlessly integrate stdlib in their fpm projects through
[dependencies]
stdlib = "*"
and have access to relatively common functions like the complex-valued gamma() that accept and return values in their supported precision.
Prior Art
No response
Additional Information
No response