Am 10.11.24 um 21:54 schrieb Harald Anlauf:
Hi Thomas,
the patch is basically fine.
I am wondering if we should create a new helper function that is
the opposite of type_check ("type_cannot_be"), so that we avoid
redundant code at the source level. It may not be worth it yet,
so your choice.
Furthermore, if you planned to list intrinsics alphabetically,
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 429d8461f8f..00276b5b45d 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
this part needs corrected (in my counting, M comes before S):
@@ -2780,6 +2781,7 @@ The following intrinsics take unsigned arguments:
@item @code{BLE}, @pxref{BLE}
@item @code{BLT}, @pxref{BLT}
@item @code{CSHIFT}, @pxref{CSHIFT}
+@item @code{CMPLX}, @pxref{CMPLX}
@item @code{DIGITS}, @pxref{DIGITS}
@item @code{DOT_PRODUCT}, @pxref{DOT_PRODUCT}
@item @code{DSHIFTL}, @pxref{DSHIFTL}
Fixed, thanks.
Not being a native speaker, I stumbled over this:
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 9d0b752670b..d11d37761d9 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -3637,9 +3638,9 @@ Elemental function
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
@item @var{X} @tab The type may be @code{INTEGER}, @code{REAL},
-or @code{COMPLEX}.
+@code{COMPLEX} or @code{UNSIGNED}.
@item @var{Y} @tab (Optional; only allowed if @var{X} is not
-@code{COMPLEX}.) May be @code{INTEGER} or @code{REAL}.
+@code{COMPLEX}.) May be @code{INTEGER}, @code{REAL} or @code{UNSIGNED}.
^^^ Shouldn't one add "The type" before "may be"?
We don't add an explicit "The type" or similar in other places, so I
didn't change it.
Pushed as r15-5077-gf5851a5b36b7dce02553d419d90f54e321f417a4 .
Thanks for the review!
Best regards
Thomas
