[PATCH v2 0/7] fortran: Ignore unused arguments for scalarisation [PR97896]

Hello, This is the second submit of a patch series whose first version[1] was not welcome because of its C++ usage. After some thought I figured out that rewriting the series without C++ features would not be that impacting after all. So here you go, the (not so) good old-fashioned way. The prob

[PATCH v2 1/7] fortran: new wrapper class gfc_dummy_arg

Introduce a new wrapper class gfc_dummy_arg that provides a common interface to both dummy arguments of user-defined procedures (which have type gfc_formal_arglist) and dummy arguments of intrinsic procedures (which have type gfc_intrinsic_arg). gcc/fortran/ * gfortran.h (gfc_dummy_arg_ki

[PATCH v2 2/7] fortran: Tiny sort_actual internal refactoring

Preliminary refactoring to make further changes more obvious. No functional change. gcc/fortran/ * intrinsic.c (sort_actual): initialise variable and use it earlier. --- gcc/fortran/intrinsic.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/gcc/fortran/intrins

[PATCH v2 3/7] fortran: Reverse actual vs dummy argument mapping

There was originally no way from an actual argument to get to the corresponding dummy argument, even if the job of sorting and matching actual with dummy arguments was done. The closest was a field named actual in gfc_intrinsic_arg that was used as scratch data when sorting arguments of one specif

[PATCH v2 4/7] fortran: simplify elemental arguments walking

This adds two functions working with the wrapper class gfc_dummy_arg and makes usage of them to simplify a bit the walking of elemental procedure arguments for scalarization. As information about dummy arguments can be obtained from the actual argument through the just-introduced associated_dummy

[PATCH v2 5/7] fortran: Delete redundant missing_arg_type field

Now that we can get information about an actual arg's associated dummy using the associated_dummy attribute, the field missing_arg_type contains redundant information. This removes it. gcc/fortran/ * gfortran.h (gfc_actual_arglist::missing_arg_type): Remove. * interface.c (gfc_com

[PATCH v2 6/7] Revert "Remove KIND argument from INDEX so it does not mess up scalarization."

This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for its testcase. gcc/fortran/ * intrinsic.c (add_sym_4ind): Remove. (add_functions): Use add_sym4 instead of add_sym4ind. Don’t special case the index intrinsic. * iresolve.c (gfc_resolve_index_fu

[PATCH v2 7/7] fortran: Ignore unused args in scalarization [PR97896]

The KIND argument of the INDEX intrinsic is a compile time constant that is used at compile time only to resolve to a kind-specific library method. It is otherwise completely ignored at runtime, and there is no code generated for it as the library procedure has no kind argument. This confuses the

Re: [RFC, Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On Wed, Aug 04, 2021 at 02:14:07PM -0600, Sandra Loosemore wrote: > I was trying last week to run my not-yet-committed TS29113 testsuite > on a powerpc64le-linux-gnu target and ran into some problems with > the kind constants c_float128 and c_float128_complex from the > ISO_C_BINDING module; per th

Re: [RFC, Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On 8/5/21 11:33 AM, Michael Meissner wrote: At the moment, we only fully support C and C++ when changing the long double format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is invoked (and assuming you are using GLIBC 2.32 or newer). For Fortran and the other languages, the

Re: [RFC, Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On Thu, Aug 05, 2021 at 12:19:37PM -0600, Sandra Loosemore wrote: > On 8/5/21 11:33 AM, Michael Meissner wrote: > >At the moment, we only fully support C and C++ when changing the long double > >format (between IEEE 128-bit, IBM 128-bit, and 64-bit) when the compiler is > >invoked (and assuming you