the attached patch allows KIND arguments to MINLOC and MAXLOC.
There was a bit of a choice to make here. Originally, I wanted to
run the calculation using index_type only and convert to another
integer kind if that was required. This ran into the issue that
bounds checking fails for this approach if there is a conversion
( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82660 ), and I
got regressions for that.
On the other hand, I wanted to avoid adding kind=1 and kind=2 versions
to the library. This approach had been rejected some time ago,
in 2009.
So, I chose a third path by using only pre-existing library
functions for kind=4, kind=8 and kind=16 and by doing a conversion
if the user specified kind=1 or kind=2.
This introduces a bug (array bounds violation not caught) if the user
- specifies bounds checking
- choses kind=1 or kind=2 for minloc or maxloc (it escapes me why
anybody would want to do that)
- uses an array as return value whose bounds cannot be determined
at compile-time, and gets the dimension of that array wrong
Frankly, if anybody would do this, the expression "deserves to lose"
comes to mind.
This would not be a regression, because kind=1 and kind=2 are
not supported at the moment. This bug would be fixed together
with 82660.
Regression-tested. OK for trunk?
Regards
Thomas
2017-10-28 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/29600
* gfortran.h (gfc_check_f): Replace fm3l with fm4l.
* intrinsic.h (gfc_resolve_maxloc): Add gfc_expr * to argument
list in protoytpe.
(gfc_resolve_minloc): Likewise.
* check.c (gfc_check_minloc_maxloc): Handle kind argument.
* intrinsic.c (add_sym_3_ml): Rename to
(add_sym_4_ml): and handle kind argument.
(add_function): Replace add_sym_3ml with add_sym_4ml and add
extra arguments for maxloc and minloc.
(check_specific): Change use of check.f3ml with check.f4ml.
* iresolve.c (gfc_resolve_maxloc): Handle kind argument. If
the kind is smaller than the smallest library version available,
use gfc_default_integer_kind and convert afterwards.
(gfc_resolve_minloc): Likewise.
2017-10-28 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/29600
* gfortran.dg/minmaxloc_8.f90: New test.