[pushed 0/3][gcc11] fortran: Backpoprt KIND arg of intrinsics fix [PR103789]

on x86_64-linux on the 11 branch, pushed. Mikael Morin (3): Fortran: Fix KIND argument index for LEN_TRIM. Fortran: Ignore KIND argument of a few more intrinsics. [PR103789] testsuite: Enrich tests with variants failing on the branch. gcc/fortran/trans-array.c | 45

[pushed] fortan testsuite: Enrich tests with variants failing on the branch.

Hello, I have just pushed the attached patch after testing the impacted tests individually. MikaelFrom 15630e6e9eb019477d1fc5c0966b43979e18ae18 Mon Sep 17 00:00:00 2001 From: Mikael Morin Date: Sun, 16 Jan 2022 18:33:36 +0100 Subject: [PATCH] testsuite: Enrich tests with variants failing

Re: [PATCH] Fortran: make IEEE_VALUE produce signaling NaNs

Hello, Le 10/01/2022 à 18:32, FX via Fortran a écrit : Hi, Second part of a three-patch series to fix PR 82207 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do so, I switched that

Re: [PATCH] PR fortran/67804 - ICE on data initialization of type(character) with wrong data

Le 12/01/2022 à 21:29, Harald Anlauf via Fortran a écrit : Dear Fortranners, the attached patch improves error recovery after an invalid structure constructor has been detected in a DATA statement. Testcase by Gerhard. Regtested on x86_64-pc-linux-gnu. OK for mainline? This should be a

Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

Le 06/01/2022 à 22:44, Mikael Morin a écrit : Le 06/01/2022 à 20:50, Harald Anlauf a écrit : Did you find the time to try your version? Not yet. But I have not (yet) forgotten about this. I have looked at it, and it enables infinite mutual recursion between gfc_intrinsic_func_interface

Re: [PATCH] Fortran: make IEEE_CLASS recognize signaling NaNs

Le 09/01/2022 à 11:52, FX via Fortran a écrit : ping Le 2 janv. 2022 à 11:50, FX a écrit : Hi, This is the first part of a three-patch series to fix PR 82207 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle signaling NaNs. This part fixes the library code

Re: [PATCH] PR fortran/101762 - ICE on non-constant pointer initialization targets

Le 03/01/2022 à 20:45, Harald Anlauf via Fortran a écrit : Dear all, the initial-data-target for a pointer initialization can be either NULL() or a non-constant target. In the latter case subscripts of the target specification (or substring starting and ending points) must be constant

Re: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]

Le 09/01/2022 à 15:10, Mikael Morin a écrit : pulling the latest master brought me a broken bootstrap It was a user error (of course). Bootstrap and regression test and commit pending. Now tested and committed as r12-6386-gc1c17a43e172ebc28f2cd247f6e83c5fdbc6219f

[PATCH] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]

c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f Mon Sep 17 00:00:00 2001 From: Mikael Morin Date: Fri, 7 Jan 2022 22:34:59 +0100 Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789] After PR97896 for which some code was added to ignore the KIND argument of the INDEX

Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

Le 06/01/2022 à 20:50, Harald Anlauf a écrit : Did you find the time to try your version? Not yet. But I have not (yet) forgotten about this.

Re: [PATCH] Emit correct types for CHARACTER(C_CHAR), VALUE

Le 26/12/2021 à 21:09, FX via Fortran a écrit : OK to commit? This looks good, yes. Thanks.

Re: [PATCH] PR fortran/103777 - ICE in gfc_simplify_maskl, at fortran/simplify.c:4918

Le 20/12/2021 à 23:05, Harald Anlauf via Fortran a écrit : Dear all, we need to check the arguments of the elemental MASKL and MASKR intrinsics also before simplifying. Testcase by Gerhard. The fix is almost obvious, but I'm happy to get feedback in case there is something I overlooked.

Re: [PATCH, v2] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

Le 13/12/2021 à 21:27, Harald Anlauf via Fortran a écrit : Works better with patch attached... Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches: The code is so similar (for good reason) that it makes sense to keep it synchronous.  I added code for 'zero_sized' array with the minor

Re: [PATCH] PR fortran/103606 - [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

On 10/12/2021 22:49, Harald Anlauf via Fortran wrote: Dear all, when accessing CLASS components we need to ensure that the corresponding class container has already been built. Invalid code, e.g. the testcase in PR103606, may otherwise generate segfaults due to invalid reads. Regtested on

Re: [PATCH, v2] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

On 09/12/2021 23:05, Harald Anlauf wrote: Hi Mikael, Am 08.12.21 um 10:32 schrieb Mikael Morin: On 07/12/2021 21:46, Harald Anlauf wrote: Hi Mikael, Am 07.12.21 um 21:17 schrieb Mikael Morin: The existing code looks dubious to me (or at least difficult to understand), and your patch doesn’t

Re: [PATCH] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays

Hello, On 09/12/2021 21:05, Harald Anlauf via Fortran wrote: Dear all, I had thought that we had fixed this in the past (see PR31001), but it did fail for me with all gcc versions I have tried (7-12) for a slightly more elaborate case as in the old testcase. The loop in pack_internal did try

Re: [PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

On 07/12/2021 21:46, Harald Anlauf wrote: Hi Mikael, Am 07.12.21 um 21:17 schrieb Mikael Morin: Hello, On 05/12/2021 22:55, Harald Anlauf via Fortran wrote: Dear all, the check of dummy arguments with pointer attribute and INTENT(IN) was broken in the case the argument was passed

Re: [PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

On 07/12/2021 21:43, Harald Anlauf via Fortran wrote: I haven't figured out yet how to kill or fix the array decl in that case. As long as an error is reported, and the compiler doesn’t crash after it, I’m not sure there is something more to fix. Nevertheless it makes sense to catch

Re: [PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

Hello, On 05/12/2021 22:55, Harald Anlauf via Fortran wrote: Dear all, the check of dummy arguments with pointer attribute and INTENT(IN) was broken in the case the argument was passed to an intrinsic. We therefore rejected valid code as e.g. given in the PR. The patch relaxes the excessive

Re: [PATCH] PR fortran/103591 - ICE in gfc_compare_string, at fortran/arith.c:1119

On 06/12/2021 23:19, Harald Anlauf via Fortran wrote: Dear all, we didn't check the type of the upper bound in a case range. Bummer. Simply add a corresponding check. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK, Thanks.

Re: [PATCH] PR fortran/103588 - ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407

Hello, On 06/12/2021 23:39, Harald Anlauf via Fortran wrote: diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index 5762c8d92d4..5f9ed17f919 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -2403,11 +2403,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t *result,

Re: [PATCH] PR fortran/103505 - ICE in compare_bound_mpz_t, at fortran/resolve.c:4587

On 02/12/2021 22:48, Harald Anlauf via Fortran wrote: Dear Fortranners, specifying invalid constant array declarations (e.g. real array bounds) could lead to an ICE because the array specs were checked for consistency. A possible solution is to try an early simplification before doing that

Re: [PATCH, fortran] Improve expansion of constant array expressions within constructors

Hello, On 27/11/2021 21:56, Harald Anlauf via Fortran wrote: diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index 6552eaf3b0c..fbc66097c80 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -1804,6 +1804,12 @@ expand_constructor (gfc_constructor_base base) if

Re: [PATCH] Avoid some -Wunreachable-code-ctrl

On 30/11/2021 14:25, Richard Biener wrote: On Tue, 30 Nov 2021, Mikael Morin wrote: Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit : diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c index f5ba7cecd54..16ee2afc9c0 100644 --- a/gcc/fortran/frontend

Re: [PATCH] Avoid some -Wunreachable-code-ctrl

Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit : diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c index f5ba7cecd54..16ee2afc9c0 100644 --- a/gcc/fortran/frontend-passes.c +++ b/gcc/fortran/frontend-passes.c @@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr

Re: [PATCH] PR fortran/103473 - [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287

Le 29/11/2021 à 23:01, Harald Anlauf via Fortran a écrit : Dear all, another trivial and obvious one, discovered by Gerhard. We can have a NULL pointer dereference simplifying MINLOC/MAXLOC on an array that was not properly declared. OK for mainline / affected 11-branch after regtesting

Re: [PATCH] PR fortran/101565 - ICE in gfc_simplify_image_index, at fortran/simplify.c:8234

Hello, Le 29/11/2021 à 22:31, Harald Anlauf via Fortran a écrit : Dear all, a trivial one: we need to check the type of the SUB argument to the coarray IMAGE_INDEX intrinsic. It has to be an array of type integer. Patch by Steve Kargl. I hope at some point he’ll finally come to a working

Re: [PATCH, v3] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

Le 26/11/2021 à 21:07, Harald Anlauf a écrit : That should hopefully be the final version... Yes it is OK. Thanks for your patience. Mikael

Re: [PATCH, v2] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

Le 25/11/2021 à 22:52, Harald Anlauf a écrit : > > Motivated by your reasoning I tried gfc_reduce_init_expr. That attempt > failed miserably (many regressions), and I think it is not right. > Then I found that array sections posed a problem that wasn't detected > before. gfc_simplify_expr

Re: [PATCH] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

Le 25/11/2021 à 21:03, Harald Anlauf a écrit : Hi Mikael, Am 25.11.21 um 17:46 schrieb Mikael Morin: Hello, Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit : diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c index 5a5aca10ebe..837eb0912c0 100644 --- a/gcc/fortran/check.c +++ b

Re: [PATCH] PR fortran/103411 - ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

Hello, Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit : diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c index 5a5aca10ebe..837eb0912c0 100644 --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -4866,10 +4868,17 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,

Re: [PATCH] PR fortran/103392 - [9/10/11/12 Regression] ICE in simplify_bound, at fortran/simplify.c:4273

Le 23/11/2021 à 21:46, Harald Anlauf via Fortran a écrit : Dear all, in simplify_bound we did hit an assert when trying to simplify LBOUND/UBOUND for arrays with allocatable or pointer attribute. We cannot do that. Terminate simplification in that situation. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim

Le 22/11/2021 à 21:30, Bernhard Reutner-Fischer a écrit : 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

Re: [PATCH] fortran, debug: Fix up DW_AT_rank [PR103315]

Le 19/11/2021 à 10:40, Jakub Jelinek via Fortran a écrit : Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Hello, you know probably better than me or any fortran maintainer whether it’s good or bad. So OK from the fortran side.

Re: [PATCH] PR fortran/87851 - [9/10/11/12 Regression] Wrong return type for len_trim

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

Re: [PATCH] PR fortran/99061 - [10/11/12 Regression] ICE in gfc_conv_intrinsic_atan2d, at fortran/trans-intrinsic.c:4728

Le 15/11/2021 à 22:38, Harald Anlauf via Fortran a écrit : Dear Fortranners, the attached patch fixes the handling of the DEC trigonometric intrinsics for different argument kinds. It is based on the original patch by Steve, which fixes the lookup for the needed intrinsics. Regtested on

[committed] fortran: Ignore unused arguments for scalarisation [PR97896]

Committed as r12-5192. 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 function. That argument is otherwise completely ignored at runtime, and there is no code generated for it as the library procedure

[PATCH v3 5/5] fortran: Identify arguments by their names

This provides a new function to get the name of a dummy argument, so that identifying an argument can be made using just its name instead of a mix of name matching (for keyword actual arguments) and argument counting (for other actual arguments). gcc/fortran/ChangeLog: * interface.c

[PATCH 2/2] 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 function. That argument is otherwise completely ignored at runtime, and there is no code generated for it as the library procedure has no kind argument.

[PATCH 1/2] Revert "Remove KIND argument from INDEX so it does not mess up scalarization."

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

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

in patch 1. I intend to commit both of them squashed together. Regression-tested on x86_64-linux-gnu. Ok for master and 11 branch? Changes from v1: Rebase on master. [1] https://gcc.gnu.org/pipermail/fortran/2021-August/056329.html Mikael Morin (2): Revert "Remove KIND argument

[PATCH v3 3/5] fortran: simplify elemental arguments walking

This adds two functions working with the wrapper struct 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

[PATCH v3 4/5] 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/ChangeLog: * gfortran.h (gfc_actual_arglist::missing_arg_type): Remove. *

[PATCH v3 2/5] 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

[PATCH v3 0/5] fortran: Ignore unused arguments for scalarisation [PR97896]

https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html [2] https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html [3] https://gcc.gnu.org/pipermail/fortran/2021-August/056329.html Mikael Morin (5): fortran: Tiny sort_actual internal refactoring fortran: Reverse actual vs dummy argument m

[PATCH v3 1/5] fortran: Tiny sort_actual internal refactoring

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

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

Le 07/11/2021 à 00:56, Bernhard Reutner-Fischer a écrit : On Sat, 6 Nov 2021 13:04:07 +0100 Mikael Morin wrote: Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit : On Fri, 5 Nov 2021 19:46:16 +0100 Mikael Morin wrote: I’m a bit concerned by the loss of the null_expr’s type

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

Sorry, I hadn’t seen your message. Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit : On Fri, 5 Nov 2021 19:46:16 +0100 Mikael Morin wrote: Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit : On Wed, 27 Oct 2021 23:39:43 +0200 Bernhard Reutner-Fischer wrote

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

Le 05/11/2021 à 19:46, Mikael Morin a écrit : Don’t you get the same effect on the memory leaks if you keep just the following hunk? >>> @@ -1605,8 +1608,7 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns, >>> /* Set up the namespace. 

Re: [PATCH] Fortran: Diagnose all operands/arguments with constraint violations

Le 05/11/2021 à 03:58, Sandra Loosemore a écrit : This is an expanded version of the patch for PR 101337 that Bernhard sent out a few days ago with a request for me to finish it.  Bernhard did the part for operands and I added the pieces for procedure arguments and intrinsics, along with

Re: [PATCH] PR fortran/102715 - [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184

Le 31/10/2021 à 22:35, Harald Anlauf via Fortran a écrit : Dear Fortranners, the fix for initialization of DT arrays caused an apparent regression for cases where inconsistent ranks were used in such an initialization. This caused either an ICE in subsequent uses of these arrays, or showed up

Re: *PING* [PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

Le 04/11/2021 à 20:49, Harald Anlauf via Fortran a écrit : Let's see what others think. OK, thanks. Mikael

Re: [PATCH] PR fortran/102817 - [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422

Le 01/11/2021 à 22:39, Harald Anlauf via Fortran a écrit : Dear Fortranners, a recent patch uncovered a latent issue with simplification of array-valued expressions where the resulting shape was not set from the referenced subobject. Once found, the fix looks obvious. Regtested on

Re: [PATCH] Fortran: Missing error with IMPLICIT none (external) [PR100972]

Le 31/10/2021 à 18:25, Bernhard Reutner-Fischer via Fortran a écrit : As Gerhard Steinmetz noticed, gfc_match_implicit_none() had a notify_std that mentioned IMPORT instead of IMPLICIT. Fix that typo. IMPLICIT NONE (external) is supposed to require external procedures to be explicitly declared

Re: [PATCH,Fortran 1/1] Tweak locations around CAF simplify

Le 27/10/2021 à 23:29, Bernhard Reutner-Fischer via Fortran a écrit : From: Bernhard Reutner-Fischer addresses: FIXME: gfc_current_locus is wrong by using the locus of the current intrinsic. Regtests clean, ok for trunk? Hello, I’m not convinced that replacing a global variable by an other

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit : On Wed, 27 Oct 2021 23:39:43 +0200 Bernhard Reutner-Fischer wrote: Ping [hmz. it's been a while, I'll rebase and retest this one. Ok if it passes?] Testing passed without any new regressions. Ok for trunk? thanks, On

Re: [PATCH,Fortran] Fortran: Delete unused decl in gfortran.h

Le 27/10/2021 à 23:11, Bernhard Reutner-Fischer via Fortran a écrit : Delete some more declarations without definitions and make some functions static. Bootstrapped and regtested on x86_64-unknown-linux without regressions. Ok for trunk? Ok. Thanks Mikael

[PATCH 1/2] 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

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

. This is the patch 2 of the series, preceded with the revert in patch 1. I intend to commit both of them squashed together. Regression-tested on x86_64-linux-gnu. Ok for 11 branch? [1] https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html Mikael Morin (2): Revert "Remove KIND arg

[PATCH 2/2] 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

[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

[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

[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

[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

[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

[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

[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

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

parate patch for the release branch with only patch 6 and 7 and the next->next->next indirections. Regression-tested on x86_64-linux-gnu. Ok for master? [1] https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html Mikael Morin (7): fortran: new wrapper class gfc_dummy_arg f

Re: [PATCH 1/7] fortran: new abstract class gfc_dummy_arg

Le 04/08/2021 à 09:05, Thomas Koenig a écrit : So far, we have refrained from adding too much explicit C++-isms into the code, and if we do, my participation at least will have to be reduced sharply (I don't speak much C++, and I don't intend to learn). So, is this a path we want to go down?

[PATCH 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

[PATCH 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

[PATCH 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

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

This adds two methods to the abstract 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 field, there is

[PATCH 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

[PATCH 1/7] fortran: new abstract class gfc_dummy_arg

Introduce a new abstract 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

[PATCH 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

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

submit a separate patch for the release branch with only patch 6 and 7 and the next->next->next indirections. Regression-tested on x86_64-linux-gnu. Ok for master? Mikael Morin (7): fortran: new abstract class gfc_dummy_arg fortran: Tiny sort_actual internal refactoring fortran: Rever

Re: [patch,fortran] Bug 69497 - ICE in gfc_free_namespace

Le 26/03/2018 à 03:53, Jerry DeLisle a écrit : On 03/25/2018 02:11 PM, Mikael Morin wrote: Le 25/03/2018 à 21:27, Jerry DeLisle a écrit : On 03/25/2018 10:49 AM, Mikael Morin wrote: Le 25/03/2018 à 00:25, Jerry DeLisle a écrit : On 03/24/2018 02:56 PM, Steve Kargl wrote: On Sat, Mar 24

Re: [patch, fortran] Fix PR 82567

Le 18/10/2017 à 04:05, Steve Kargl a écrit : On Tue, Oct 17, 2017 at 06:14:16PM -0700, Jerry DeLisle wrote: On 10/17/2017 03:36 PM, Thomas Koenig wrote: Hello world, this patch fixes a regression with long compile times, which came about due to our handling of array constructors at compile

Re: [patch, fortran, committed] Small -fdump-fortran-original fixes, plus documentation update

Hello, Le 08/10/2017 à 15:15, Paul Richard Thomas a écrit : I thought that the suggestion to add the original input lines was not bad. It would be even better if -fdump-tree-original could do that. There is -fdump-tree-original-lineno. I think it does that. Cheers Mikael

Re: [fortran, RFC] Getting rid of unneeded functions in libgfortran

Hello, Le 10/07/2017 à 20:43, Thomas Koenig a écrit : Hello world, with the bump in the libfortran version that is needed with Paul's patch, I think we can get rid of a few functions that we do not actually need any more. I think we now always inline SUM and PRODUCT. We don't do so with all

Re: [PATCH] gfortran -- Map REAL128 to REAL kind type with widest precision

Le 08/02/2017 à 10:25, FX a écrit : Hi Steve, I see Mikael has okayed the patch, but I did not have any time to comment prior. I wanted to note that: - the choice was deliberate, as the standard allows us to choose which real kind REAL128 corresponds to when there are several matching

Re: [PATCH] gfortran -- Map REAL128 to REAL kind type with widest precision

Le 07/02/2017 à 19:46, Steve Kargl a écrit : All, The attach patch maps REAL128 from iso_fortran_env to the REAL kind type with widest precision. Prior to this patch, REAL128 is mapped to the first REAL kind type with a matching storage size of 128 bits. On x86_64-*-freebsd both REAL(10) and

Re: [PATCH, Fortran, pr79344, v1] [7 Regression] segmentation faults and run-time errors

Le 04/02/2017 à 19:43, Andre Vehreschild a écrit : Hi all, attached patch fixes the issue of losing the data in the SOURCE= expression of an ALLOCATE() when the source-expression is just a simple variable. The issue was that internally a temporary variable was created, whose components were

Re: [Patch, Fortran, committed] PR 78592: [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

Le 17/12/2016 à 22:49, Janus Weil a écrit : Hi Mikael, I have just committed a completely obvious patch for this PR. All it does is rearrange some expressions to avoid an ICE (see attachment): I have made a late review of it, and I think it’s not as innocent as it seems. With it, if the

Re: [Patch, Fortran, committed] PR 78592: [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

Hello, Le 30/11/2016 à 10:52, Janus Weil a écrit : Hi all, I have just committed a completely obvious patch for this PR. All it does is rearrange some expressions to avoid an ICE (see attachment): I have made a late review of it, and I think it’s not as innocent as it seems. With it, if the

Re: [patch, fortran] Fix ICEs with -fimplicit-none

Le 11/12/2016 à 23:21, Thomas Koenig a écrit : Hello world, the attached patch fixes a 5/6/7 regression with -fimplicit-none. Regression-tested. OK for all affected branches? OK. Thanks Mikael

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

Hello, Le 09/12/2016 à 11:55, Andre Vehreschild a écrit : Hi Mikael, thanks a lot for your comments. Note I also have added the reply to your latest email here. On Thu, 8 Dec 2016 23:49:57 +0100 Mikael Morin <morin-mik...@orange.fr> wrote: diff --git a/gcc/fortran/data.c b/gcc/f

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

Hello, Le 08/12/2016 à 23:49, Mikael Morin a écrit : Le 08/12/2016 à 14:39, Andre Vehreschild a écrit : diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 2e6ef2a..8173ba9 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1019,7 +1019,7

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

Le 08/12/2016 à 14:39, Andre Vehreschild a écrit : Hi all, hi Dominique, this is the "compile time part 1" (ctp1) patch to fix the issues reported in gfortran by a sanitized compiler when compiling the testsuite. The patch addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false".

Re: [Patch, fortran, RFC] Add warning for missing location information

Le 08/12/2016 à 22:50, Thomas Koenig a écrit : Am 08.12.2016 um 21:01 schrieb Mikael Morin: Le 08/12/2016 à 20:26, Thomas Koenig a écrit : Hi Andre, Thomas, your part of the patch looks ok to me, too. I haven't tracked the discussion on whether it is ok to add your part of the patch

Re: [Patch, fortran, RFC] Add warning for missing location information

Le 08/12/2016 à 20:26, Thomas Koenig a écrit : Hi Andre, Thomas, your part of the patch looks ok to me, too. I haven't tracked the discussion on whether it is ok to add your part of the patch. Therefore I don't have committed your patch. My opinion is, that it does do no harm. So it should be

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

Le 11/11/2016 à 19:30, Steve Kargl a écrit : On Fri, Nov 11, 2016 at 03:05:06PM +0100, Janus Weil wrote: 2016-11-11 14:38 GMT+01:00 Janus Weil : [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance why it is necessary to nullify 'result->n.tb' on a

Re: [PATCH, Fortran, v1] Restructure initialization of allocatable components

Le 03/11/2016 à 14:16, Andre Vehreschild a écrit : @Dominique: Would you give it a go on your open patch collection? Maybe it fixes one PR, but I am not very hopeful, because the patch is merely removing complexity instead of doing new things. Hello, Since you asked: I think the patch fixes

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

Hello, Le 26/08/2016 à 20:27, Steve Kargl a écrit : Here are two possible patches for PR fortran/77391. The first patch treats the invalid code as a GNU Fortran extension as gfortran current accepts the invalid code. The second patch enforces the standard. As I think gfortran should

Re: [patch, Fortran] Fix PR 71902

Le 18/08/2016 à 21:24, Thomas Koenig a écrit : Hello Mikael, This doesn't look correct, what about substrings following component or array references? You're right; corrected in the attached patch. I have also added a test case for this. PS: What about the original fix, wasn't it a

Re: [PATCH] Fix up trans_array_constructor UB (PR fortran/67496)

Le 17/08/2016 à 20:56, Jakub Jelinek a écrit : Hi! The bug here is that it dereferences expr->ts.u.cl if non-NULL unconditionally, no matter what expr->ts.type is. But, ts.u is an union, where ts.u.cl is only valid for BT_CHARACTER, ts.u.derived for BT_DERIVED etc. ts.u.pad (an int rather than

Re: [patch, Fortran] Fix PR 71902

Hello, Le 14/08/2016 à 15:05, Thomas Koenig a écrit : Index: frontend-passes.c === --- frontend-passes.c (Revision 239218) +++ frontend-passes.c (Arbeitskopie) @@ -177,6 +178,13 @@ realloc_string_callback (gfc_code **c, int

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

Le 20/07/2016 à 11:39, Andre Vehreschild a écrit : Hi Mikael, + if(st == ST_FAIL_IMAGE) +new_st.op = EXEC_FAIL_IMAGE; + else +gcc_unreachable(); You can use gcc_assert (st == ST_FAIL_IMAGE); foo...; instead of if (st == ST_FAIL_IMAGE) foo...;

Re: [Fortran, Patch] First patch for coarray FAILED IMAGES (TS 18508)

Hello, this is mostly good in general, but is lacking tests. Especially, tests for successfull matching, and tests for every error you are adding in the patch (except maybe the -fcoarray= one). Also tests that the code executes successfullly with -fcoarray=single, and that it produces the

<    1   2   3   4   5   6   7   8   9   10   >