Le 05/07/2026 à 22:39, Harald Anlauf a écrit :
[Argh, pressed send too early...]
Dear all,
this patch fills in a gap for the degree trigonometric functions: there
is a library version with C calling conventions (by value), but the
Fortran wrappers were missing. For their use as procedure pointer
target one needed to use the proper isym in resolution and generate
the proper library name in line with our conventions.
The new wrappers were coded manually.
The radian functions were made one way, and now the degree ones some
other way. That's a bit unfortunate, even if the maintenance burden
should be rather low. What didn't work with regenerate.sh and
Makefile.am? Was it the autoconf/automake version? I can see that you
managed to regenerate Makefile.in.
The rest looks good. I understand little of it though.
Mikael
I was not entirely sure if
the kind=16/17 handling is fine, so feedback is appreciated.
The testcase checks both the F2023 variants as well as the existing
GNU intrinsic extensions. (Non-existing GNU extensions were removed
from the documentation.)
I checked that the testcase passes locally also when specifying
-freal-4-real-8, -freal-4-real-10, -freal-4-real-16,
-freal-8-real-10, and -freal-8-real-16,
but I chose to not test this explicitly in the testsuite.
If it is felt important, it can be added.
Regtested cleanly on x86_64-pc-linux-gnu. OK for mainline?
Do we want a backport to 16-branch? If this is the case,
I would need to adjust gfortran.map accordingly.
Thanks,
Harald
