Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim
Am 21.11.21 um 12:46 schrieb Mikael Morin: Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit : Dear Fortranners, scalariziation of the elemental intrinsic LEN_TRIM was ICEing when the optional KIND argument was present. The cleanest solution is to use the infrastructure added by Mikael's fix for PR97896. In that case it is a 1-liner. :-) That fix is available on mainline and on 11-branch only, though. My suggestion is to fix the current PR only for the same branches, leaving the regression unfixed for older ones. Regtested on x86_64-pc-linux-gnu. OK for mainline and 11-branch? Your change itself is fine. The PR was originally about a type mismatch between the gfortran library and the call generated by the front-end. The supposed type mismatch was due to Janne's commit r8-5772: commit f61ab42c4ca550059add89ffda00ed2b3c03 Author: Janne Blomqvist Date: Fri Jan 5 21:01:12 2018 +0200 PR 78534 Change character length from int to size_t In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. [...] LEN_TRIM is of course of type default integer, which is handled fine in gfc_resolve_len_trim, setting f->ts.kind, the same way as it is done in gfc_resolve_index_func or elsewhere, and conversions are properly taken care of as far as I can tell. Things work(ed) fine for the "scalar" version of LEN_TRIM, even if the optional KIND argument was present, before the above commit. But not the elemental version working on rank>=1 with KIND present. That did not change. See PR87711. Thinking again, the patch primarily addresses PR87711 (for 11/12) and fixes some of the comments in PR87851. We'd need to find out what exactly is left from the latter. The dump-tree of the testcase looks fine to me, even when compiling with -fdefault-integer-8, and I do not see any conversion warnings. As the code generated contains a cast, I think it’s fine as well. Well, LEN_TRIM is of default integer, unless KIND is given. But please give Thomas (bug reporter) one more day to comment on this. Sure. Then I think you can proceed. Thanks. Thanks, Harald
Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim
On Mon, 22 Nov 2021 19:17:51 +0100 Harald Anlauf via Gcc-patches wrote: > Am 21.11.21 um 12:46 schrieb Mikael Morin: > > Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit : > >> Dear Fortranners, > >> > >> scalariziation of the elemental intrinsic LEN_TRIM was ICEing > >> when the optional KIND argument was present. > >> > >> The cleanest solution is to use the infrastructure added by > >> Mikael's fix for PR97896. In that case it is a 1-liner. :-) I'm just wondering loud if it would be more convenient to have a unsigned hidden_arg:1 bit in let's say gfc_actual_arglist that denotes if the argument should be const eval'ed and used before, and, most importantly not passed to the library. We seem to have more than just the index intrinsic's kind arg in that boat. And from what i read, powerpc will eventuall want to select quite some kind-specific library functions soon, depending on how this part is implemented.. Maybe add SPEC_HIDDEN_ARG / SPEC_LIBRARY_SELECTOR additional gfc_param_spec_type if a separate bit is deemed inappropriate. Such a hidden_arg/library_selector/non_library_call_arg flag is maybe better than matching individual functions and strcmp the arg name. cheers,
Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim
Am 22.11.21 um 21:30 schrieb Bernhard Reutner-Fischer via Fortran: On Mon, 22 Nov 2021 19:17:51 +0100 Harald Anlauf via Gcc-patches wrote: Am 21.11.21 um 12:46 schrieb Mikael Morin: Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit : Dear Fortranners, scalariziation of the elemental intrinsic LEN_TRIM was ICEing when the optional KIND argument was present. The cleanest solution is to use the infrastructure added by Mikael's fix for PR97896. In that case it is a 1-liner. :-) I'm just wondering loud if it would be more convenient to have a unsigned hidden_arg:1 bit in let's say gfc_actual_arglist that denotes if the argument should be const eval'ed and used before, and, most importantly not passed to the library. We seem to have more than just the index intrinsic's kind arg in that boat. And from what i read, powerpc will eventuall want to select quite some kind-specific library functions soon, depending on how this part is implemented.. Well, that does not make sense for KIND, which has to be constant. We even have an appropriate check for this in check.c(kind_check). And KIND may even select a special library function, which means that KIND cannot be an ordinary function argument. Maybe add SPEC_HIDDEN_ARG / SPEC_LIBRARY_SELECTOR additional gfc_param_spec_type if a separate bit is deemed inappropriate. Such a hidden_arg/library_selector/non_library_call_arg flag is maybe better than matching individual functions and strcmp the arg name. cheers,
