[gcc r15-1893] fortran: Move definition of variable closer to its uses

https://gcc.gnu.org/g:7183a8ca18d5889a1f66ec1edbda00200d700c6c commit r15-1893-g7183a8ca18d5889a1f66ec1edbda00200d700c6c Author: Mikael Morin Date: Mon Jul 8 09:38:42 2024 +0200 fortran: Move definition of variable closer to its uses No change of behaviour, this makes a variable

[PATCH] fortran: Remove useless nested end of scalarization chain handling

Hello, this is another small cleanup I had lying around. Regression-tested on x86_64-linux. Ok for master? -- 8< -- Remove the special handling of end of nested scalarization chains, which advanced the chain to an element of a parent chain when the current one was reaching its end. That

[PATCH] fortran: Move definition of variable closer to its uses

Hello, I have found this small cleanup lying in a local branch. Regression-tested on x86_64-linux, OK for master? -- 8< -- No change of behaviour, this makes a variable easier to track. gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_preloop_setup): Use a separate variable

[gcc(refs/users/mikael/heads/cleanup_trans_preloop_setup_v01)] fortran: Move definition of variable closer to its usages

https://gcc.gnu.org/g:cfcb4489798cfb9715e8cf92bb8eadcfe35dfd21 commit cfcb4489798cfb9715e8cf92bb8eadcfe35dfd21 Author: Mikael Morin Date: Mon Nov 20 10:16:31 2023 +0100 fortran: Move definition of variable closer to its usages No change of behaviour, this makes a variable easier

[gcc] Created branch 'mikael/heads/cleanup_trans_preloop_setup_v01' in namespace 'refs/users'

The branch 'mikael/heads/cleanup_trans_preloop_setup_v01' was created in namespace 'refs/users' pointing to: cfcb4489798... fortran: Move definition of variable closer to its usages

[gcc(refs/users/mikael/heads/cleanup_advance_se_ss_chain_v01)] fortran: Remove useless nested end of scalarization chain handling

https://gcc.gnu.org/g:c633926356155181081154c094010d672e715a4e commit c633926356155181081154c094010d672e715a4e Author: Mikael Morin Date: Mon Nov 20 16:15:45 2023 +0100 fortran: Remove useless nested end of scalarization chain handling Remove the special handling of end of nested

[gcc] Created branch 'mikael/heads/cleanup_advance_se_ss_chain_v01' in namespace 'refs/users'

The branch 'mikael/heads/cleanup_advance_se_ss_chain_v01' was created in namespace 'refs/users' pointing to: c6339263561... fortran: Remove useless nested end of scalarization chain h

[gcc(refs/users/mikael/heads/non_lvalue_match.pd_v01)] match: Unwrap non-lvalue as unary or binary operand

https://gcc.gnu.org/g:b3cc0b4da1b94e3b3c2895011ab8d19d1268c34b commit b3cc0b4da1b94e3b3c2895011ab8d19d1268c34b Author: Mikael Morin Date: Thu Jul 4 15:24:36 2024 +0200 match: Unwrap non-lvalue as unary or binary operand gcc/ChangeLog: * match.pd: Unwrap

[gcc(refs/users/mikael/heads/non_lvalue_match.pd_v01)] match: Simplify double not and double negate to a non_lvalue

https://gcc.gnu.org/g:540cb6b0dd2a9ece734e927d520a9ca15e8afff8 commit 540cb6b0dd2a9ece734e927d520a9ca15e8afff8 Author: Mikael Morin Date: Thu Jul 4 12:59:34 2024 +0200 match: Simplify double not and double negate to a non_lvalue gcc/ChangeLog: * match.pd: Add

[gcc] Created branch 'mikael/heads/non_lvalue_match.pd_v01' in namespace 'refs/users'

The branch 'mikael/heads/non_lvalue_match.pd_v01' was created in namespace 'refs/users' pointing to: b3cc0b4da1b... match: Unwrap non-lvalue as unary or binary operand

Re: [PATCH] Fortran: fix passing of optional dummy as actual to optional argument [PR55978]

Le 23/06/2024 à 22:58, Harald Anlauf a écrit : Dear all, the attached patch fixes issues exhibited by the testcase in comment#19 of PR55978. First, when passing an allocatable optional dummy array to an optional dummy, we need to prevent accessing the data component of the array when the

Re: gcc git locked out for hours second day in a row

Hello, Le 12/06/2024 à 16:57, Jakub Jelinek a écrit : On Wed, Jun 12, 2024 at 04:53:38PM +0200, Mikael Morin wrote: Perhaps you could create a mirror version of the repo and do some experiments locally on that to identify where the bottle-neck is coming from? Not sure where to start

Re: gcc git locked out for hours second day in a row

Le 12/06/2024 à 16:34, Richard Earnshaw (lists) a écrit : On 12/06/2024 14:23, Mikael Morin via Gcc wrote: Le 12/06/2024 à 14:58, Jonathan Wakely a écrit : On Wed, 12 Jun 2024 at 13:57, Mikael Morin via Gcc wrote: Le 12/06/2024 à 13:48, Jakub Jelinek a écrit : Hi! Yesterday the gcc git

Re: gcc git locked out for hours second day in a row

Le 12/06/2024 à 14:58, Jonathan Wakely a écrit : On Wed, 12 Jun 2024 at 13:57, Mikael Morin via Gcc wrote: Le 12/06/2024 à 13:48, Jakub Jelinek a écrit : Hi! Yesterday the gcc git repository was locked for 3 hours locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167) 78:06

Re: gcc git locked out for hours second day in a row

Le 12/06/2024 à 14:14, Mark Wielaard a écrit : Hi, On Wed, 2024-06-12 at 13:48 +0200, Jakub Jelinek via Gcc wrote: Yesterday the gcc git repository was locked for 3 hours locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167) 78:06 python hooks/update.py

Re: gcc git locked out for hours second day in a row

Le 12/06/2024 à 13:48, Jakub Jelinek a écrit : Hi! Yesterday the gcc git repository was locked for 3 hours locked by user mikael at 2024-06-11 13:27:44.301067 (pid = 974167) 78:06 python hooks/update.py refs/users/mikael/tags/fortran-dev_merges/r10-1545

Re: [COMMITTED 01/12] - Move all relation queries into relation_oracle.

Hello... Le 23/05/2024 à 22:52, Andrew MacLeod a écrit : A range-query currently provides a couple of relation query routines, plus it also provides direct access to an oracle.   This patch moves those queries into the oracle where they should be, and ands the ability to create and destroy

Re: [COMMITTED] [prange] Drop range to VARYING if the bitmask intersection made it so [PR115131]

Hello, Le 17/05/2024 à 16:03, Aldy Hernandez a écrit : If the intersection of the bitmasks made the range span the entire domain, normalize the range to VARYING. gcc/ChangeLog: PR middle-end/115131 * value-range.cc (prange::intersect): Set VARYING if intersection of

[gcc] Deleted branch 'mikael/heads/pr93635-v2_Harald' in namespace 'refs/users'

The branch 'mikael/heads/pr93635-v2_Harald' in namespace 'refs/users' was deleted. It previously pointed to: 1ea6d9d7f54... Fortran: improve attribute conflict checking [PR93635] Diff: !!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):

Re: [PATCH, v2] Fortran: improve attribute conflict checking [PR93635]

Le 23/05/2024 à 21:15, Harald Anlauf a écrit : Hi Mikael, On 5/23/24 09:49, Mikael Morin wrote: Le 13/05/2024 à 09:25, Mikael Morin a écrit : Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le

[gcc(refs/users/mikael/heads/pr93635-v2_Harald)] Fortran: improve attribute conflict checking [PR93635]

https://gcc.gnu.org/g:1ea6d9d7f541844106e9dbec0b3962cdd8695696 commit 1ea6d9d7f541844106e9dbec0b3962cdd8695696 Author: Harald Anlauf Date: Thu May 23 21:13:00 2024 +0200 Fortran: improve attribute conflict checking [PR93635] gcc/fortran/ChangeLog: PR

[gcc] Created branch 'mikael/heads/pr93635-v2_Harald' in namespace 'refs/users'

The branch 'mikael/heads/pr93635-v2_Harald' was created in namespace 'refs/users' pointing to: 1ea6d9d7f54... Fortran: improve attribute conflict checking [PR93635]

[gcc] Deleted branch 'mikael/heads/pr99798_v32' in namespace 'refs/users'

The branch 'mikael/heads/pr99798_v32' in namespace 'refs/users' was deleted. It previously pointed to: e13178f7fbd... fortran: Assume there is no cyclic reference with submodule Diff: !!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Le 23/05/2024 à 09:49, Mikael Morin a écrit : Le 13/05/2024 à 09:25, Mikael Morin a écrit : Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Le 13/05/2024 à 09:25, Mikael Morin a écrit : Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll stop here... Thanks. Go figure, I have

[gcc r15-698] fortran: Assume there is no cyclic reference with submodule symbols [PR99798]

https://gcc.gnu.org/g:38d1761c0c94b77a081ccc180d6e039f7a670468 commit r15-698-g38d1761c0c94b77a081ccc180d6e039f7a670468 Author: Mikael Morin Date: Sun May 12 15:16:23 2024 +0200 fortran: Assume there is no cyclic reference with submodule symbols [PR99798] This prevents

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Le 10/05/2024 à 21:56, Harald Anlauf a écrit : Am 10.05.24 um 21:48 schrieb Harald Anlauf: Hi Mikael, Am 10.05.24 um 11:45 schrieb Mikael Morin: Le 09/05/2024 à 22:30, Harald Anlauf a écrit : I'll stop here... Thanks. Go figure, I have no problem reproducing today. It's PR99798

[PATCH] fortran: Assume there is no cyclic reference with submodule symbols [PR99798]

Hello, Here is my final patch to fix the ICE of PR99798. It's maybe overly verbose with comments, but the memory management is hopefully clarified. I tested this with a full fortran regression test on x86_64-linux and a manual check with valgrind on the testcase. OK for master? -- 8< -- This

[gcc(refs/users/mikael/heads/pr99798_v32)] fortran: Assume there is no cyclic reference with submodule symbols [PR99798]

https://gcc.gnu.org/g:e13178f7fbd977b71602d39c401adc671fd30d16 commit e13178f7fbd977b71602d39c401adc671fd30d16 Author: Mikael Morin Date: Fri May 10 11:14:48 2024 +0200 fortran: Assume there is no cyclic reference with submodule symbols [PR99798] This prevents a premature

[gcc] Created branch 'mikael/heads/pr99798_v32' in namespace 'refs/users'

The branch 'mikael/heads/pr99798_v32' was created in namespace 'refs/users' pointing to: e13178f7fbd9... fortran: Assume there is no cyclic reference with submodule

[gcc(refs/users/mikael/heads/pr99798_v66)] fortran: Fix leaked symbol

https://gcc.gnu.org/g:4b2e3dff5615a16532f42459fc5d0400c6d61f05 commit 4b2e3dff5615a16532f42459fc5d0400c6d61f05 Author: Mikael Morin Date: Fri May 10 11:17:41 2024 +0200 fortran: Fix leaked symbol For a symbol we create, this adds a reference to a it in a namespace, so

[gcc(refs/users/mikael/heads/pr99798_v66)] fortran: Assume there is no cyclic reference with submodule symbols [PR99798]

https://gcc.gnu.org/g:934742d5d2706d3dc3df1dad7cd7ad1cfd6d6370 commit 934742d5d2706d3dc3df1dad7cd7ad1cfd6d6370 Author: Mikael Morin Date: Fri May 10 11:14:48 2024 +0200 fortran: Assume there is no cyclic reference with submodule symbols [PR99798] This prevents a premature

[gcc] Created branch 'mikael/heads/pr99798_v66' in namespace 'refs/users'

The branch 'mikael/heads/pr99798_v66' was created in namespace 'refs/users' pointing to: 4b2e3dff5615... fortran: Fix leaked symbol

Re: [PATCH] Fortran: fix dependency checks for inquiry refs [PR115039]

Le 10/05/2024 à 21:24, Harald Anlauf a écrit : Dear all, the attached simple and obvious patch fixes a bogus recursion error with inquiry refs used statement functions. The commit message says all there is to say... Regtested on x86_64-pc-linux-gnu. I intend to commit to mainline within the

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Le 09/05/2024 à 22:30, Harald Anlauf a écrit : Hi Mikael, Am 09.05.24 um 21:51 schrieb Mikael Morin: Hello, Le 06/05/2024 à 21:33, Harald Anlauf a écrit : Dear all, I've been contemplating whether to submit the attached patch. It addresses an ICE-on-invalid as reported in the PR, and also

Re: [PATCH] Fortran: improve attribute conflict checking [PR93635]

Hello, Le 06/05/2024 à 21:33, Harald Anlauf a écrit : Dear all, I've been contemplating whether to submit the attached patch. It addresses an ICE-on-invalid as reported in the PR, and also fixes an accepts-invalid (see testcase), plus maybe some more, related due to incomplete checking of

Re: [PATCHv2] Value range: Add range op for __builtin_isfinite

Le 09/05/2024 à 10:47, HAO CHEN GUI a écrit : Hi Mikael, Thanks for your comments. 在 2024/5/9 16:03, Mikael Morin 写道: I think the canonical API behaviour sets R to varying and returns true instead  of just returning false if nothing is known about the range. I'm not sure whether it makes

Re: [PATCHv2] Value range: Add range op for __builtin_isfinite

Hello, Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit : Hi, The former patch adds isfinite optab for __builtin_isfinite. https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html Thus the builtin might not be folded at front end. The range op for isfinite is needed for value range

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

Hello, Le 08/05/2024 à 07:27, Kewen.Lin a écrit : Hi, Previously effective target fortran_real_c_float128 never passes on Power regardless of the default 128 long double is ibmlongdouble or ieeelongdouble. It's due to that TF mode is always used for kind 16 real, which has precision 127,

Re: [Patch, fortran] PR114859 - [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752

Hello, Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit : Hi All, Could this be looked at quickly? The timing of this regression is more than a little embarrassing on the eve of the 14.1 release. The testcase and the comment in gfc_trans_class_init_assign explain what this problem is all

[gcc r11-11305] fortran: Ignore use statements on error [PR107426]

https://gcc.gnu.org/g:3d05b9ac1c6ad950339f9487702c3165c189fe9e commit r11-11305-g3d05b9ac1c6ad950339f9487702c3165c189fe9e Author: Mikael Morin Date: Thu Mar 21 17:27:54 2024 +0100 fortran: Ignore use statements on error [PR107426] This fixes an access to freed memory

[gcc r12-10305] fortran: Ignore use statements on error [PR107426]

https://gcc.gnu.org/g:38dd703d368c9e60159e6f19cfc8303ad639b557 commit r12-10305-g38dd703d368c9e60159e6f19cfc8303ad639b557 Author: Mikael Morin Date: Thu Mar 21 17:27:54 2024 +0100 fortran: Ignore use statements on error [PR107426] This fixes an access to freed memory

[gcc r13-8543] fortran: Ignore use statements on error [PR107426]

https://gcc.gnu.org/g:fc5c603da3c9b186308fb3afef7bcf3f3bf695e8 commit r13-8543-gfc5c603da3c9b186308fb3afef7bcf3f3bf695e8 Author: Mikael Morin Date: Thu Mar 21 17:27:54 2024 +0100 fortran: Ignore use statements on error [PR107426] This fixes an access to freed memory

[gcc r14-9703] fortran: Fix specification expression check in submodules [PR114475]

https://gcc.gnu.org/g:7f233feafd657250340be3b3500d2697948ae3ed commit r14-9703-g7f233feafd657250340be3b3500d2697948ae3ed Author: Mikael Morin Date: Wed Mar 27 16:30:42 2024 +0100 fortran: Fix specification expression check in submodules [PR114475] The patch fixing PR111781 made

[PATCH] fortran: Fix specification expression check in submodules [PR114475]

Hell(o), it didn't take long for my recent patch for PR111781 to show a regression. The fix proposed here is actually the one Harald posted in the PR. I can't imagine a case where it wouldn't do the right thing. Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- The patch fixing

[gcc r14-9619] fortran: Ignore use statements on error [PR107426]

https://gcc.gnu.org/g:a44d7e8a52007c2d45217709ca02947c6600de87 commit r14-9619-ga44d7e8a52007c2d45217709ca02947c6600de87 Author: Mikael Morin Date: Thu Mar 21 17:27:54 2024 +0100 fortran: Ignore use statements on error [PR107426] This fixes an access to freed memory

[gcc r14-9618] fortran: Fix specification expression error with dummy procedures [PR111781]

https://gcc.gnu.org/g:44c0398e65347def316700911a51ca8b4ec0a411 commit r14-9618-g44c0398e65347def316700911a51ca8b4ec0a411 Author: Mikael Morin Date: Fri Mar 22 12:32:34 2024 +0100 fortran: Fix specification expression error with dummy procedures [PR111781] This fixes a spurious

[gcc r14-9617] testsuite: Declare fortran array bound variables

https://gcc.gnu.org/g:ebace32a26424884789ccf585a24ac6a5703a323 commit r14-9617-gebace32a26424884789ccf585a24ac6a5703a323 Author: Mikael Morin Date: Fri Mar 22 12:32:17 2024 +0100 testsuite: Declare fortran array bound variables This fixes invalid undeclared fortran array bound

[PATCH] fortran: Ignore use statements on error [PR107426]

Hello, here is a fix for an ICE caused by dangling pointers to ISO_C_BINDING's C_PTR symbol in the global intrinsic symbol for C_LOC. I tried to fix it by making the intrinsic symbol use its own copy of C_PTR, but it regressed heavily. Instead, I propose this which is based on a patch I attached

Re: [PATCH, v3] Fortran: improve array component description in runtime error message [PR30802]

Le 20/03/2024 à 21:24, Harald Anlauf a écrit : Hi Mikael, all, here's now the third version of the patch that implements the following scheme: On 3/15/24 20:29, Mikael Morin wrote: Le 15/03/2024 à 18:26, Harald Anlauf a écrit : OK, that sounds interesting.  To clarify the options

[PATCH v3 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]

This fixes a spurious invalid variable in specification expression error. The error was caused on the testcase from the PR by two different bugs. First, the call to is_parent_of_current_ns was unable to recognize correct host association and returned false. Second, an ad-hoc condition coming next

[PATCH v3 1/2] testsuite: Declare fortran array bound variables

This fixes invalid undeclared fortran array bound variables in the testsuite. gcc/testsuite/ChangeLog: * gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s) as dummy argument(s). * gfortran.dg/pr101267.f90: Likewise. * gfortran.dg/pr112404.f90:

[PATCH v3 0/2] fortran: Fix specification checks [PR111781]

log text from second patch - Target current stage (stage4) instead of next (stage1) v1 -> v2 changes: - Fix condition guarding sym->result access. Mikael Morin (2): testsuite: Declare fortran array bound variables fortran: Fix specification expression error with dummy p

Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]

Le 17/03/2024 à 23:10, Harald Anlauf a écrit : Hi Mikael, On 3/17/24 22:04, Mikael Morin wrote: diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 3673fa40720..a7717a8107e 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -7526,6 +7526,17

Re: RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model

Hello, Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit : (...) gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +- looks like the patch pushed to master lost the file rename. I get a bootstrap failure caused by the missing zn4zn5.md file. Can you have a look?

Re: [PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]

it before stage 1 so that I can get rid of it sooner. On 3/17/24 17:57, Mikael Morin wrote: * expr.cc (check_restricted): Remove the case where symbol is dummy and declared in the current ns.  Use gfc_get_spec_ns to get the right namespace. Looking at the original and new code, I

Re: [PATCH, v2] Fortran: fix for absent array argument passed to optional dummy [PR101135]

Le 15/03/2024 à 20:32, Harald Anlauf a écrit : Dear all, as there has been some good progress in the handling of optional dummy arguments, I looked again at this PR and a patch for it that I withdrew as it turned out incomplete. It turned out that it now needs only a minor adjustment for

[PATCH v2 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]

This fixes a spurious invalid variable in specification expression error. The problem is caused by improper restoration of formal_arg_flag to false (instead of restoring it to its previous value). This happens with the testcase from the PR where a dummy argument is itself a procedure with dummy

[PATCH v2 1/2] testsuite: Declare fortran array bound variables

This fixes invalid undeclared fortran array bound variables in the testsuite. gcc/testsuite/ChangeLog: * gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s) as dummy argument(s). * gfortran.dg/pr101267.f90: Likewise. * gfortran.dg/pr112404.f90:

[PATCH v2 0/2] fortran: Fix specification checks [PR111781]

for master when stage1 opens? Mikael v1 -> v2 changes: - Fix condition guarding sym->result access. Mikael Morin (2): testsuite: Declare fortran array bound variables fortran: Fix specification expression error with dummy procedures [PR111781] gcc/fortran/e

[PATCH 2/2] fortran: Fix specification expression error with dummy procedures [PR111781]

This fixes a spurious invalid variable in specification expression error. The problem is caused by improper restoration of formal_arg_flag to false (instead of restoring it to its previous value). This happens with the testcase from the PR where a dummy argument is itself a procedure with dummy

[PATCH 1/2] testsuite: Declare fortran array bound variables

This fixes invalid undeclared fortran array bound variables in the testsuite. gcc/testsuite/ChangeLog: * gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s) as dummy argument(s). * gfortran.dg/pr101267.f90: Likewise. * gfortran.dg/pr112404.f90:

[PATCH 0/2] fortran: Fix specification checks [PR111781]

is involved, and enables more valid ones, as visible in the testcases from the first patch. The patch is not completely trivial, and fix what is not really a regression, so it is more for stage1, I think. Tested for regression on x86_64-pc-linux-gnu. Ok for master when stage1 opens? Mikael Morin (2

Re: [PATCH, v2] Fortran: use name of array component in runtime error message [PR30802]

Le 15/03/2024 à 18:26, Harald Anlauf a écrit : Hi Mikael, On 3/15/24 17:31, Mikael Morin wrote: Le 10/03/2024 à 22:31, Harald Anlauf a écrit : Dear all, after playing for some time with NAG and Intel, and an off-list discussion with Jerry, I am getting more and more convinced that simpler

Re: [PATCH, v2] Fortran: use name of array component in runtime error message [PR30802]

On 1/30/24 11:46, Mikael Morin wrote: Le 30/01/2024 à 11:38, Mikael Morin a écrit : Another (easier) way to clarify the data reference would be rephrasing the message so that the array part is separate from the scalar part, like so (there are too many 'of', but I lack inspiration): Index '0

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Le 30/01/2024 à 11:38, Mikael Morin a écrit : Another (easier) way to clarify the data reference would be rephrasing the message so that the array part is separate from the scalar part, like so (there are too many 'of', but I lack inspiration): Index '0' of dimension 1 of component 'zz

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Le 29/01/2024 à 21:50, Harald Anlauf a écrit : Am 29.01.24 um 18:25 schrieb Harald Anlauf: I was talking about the generated format strings of runtime error messages. program p    implicit none    type t   real :: zzz(10) = 42    end type t    class(t), allocatable :: xx(:)    integer :: j

Re: [PATCH] Fortran: NULL actual to optional dummy with VALUE attribute [PR113377]

Le 25/01/2024 à 22:26, Harald Anlauf a écrit : Dear all, this is the third patch in a series that addresses dummy arguments with the VALUE attribute, now handling the passing of NULL actual arguments. It is based on the refactoring in the previous patch and reuses the handling of absent

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

Le 24/01/2024 à 22:39, Harald Anlauf a écrit : Dear all, this patch is actually only a followup fix to generate the proper name of an array reference in derived-type components for the runtime error message generated for the bounds-checking code. Without the proper part ref, not only a user

Re: [PATCH] Fortran: passing of optional dummies to elemental procedures [PR113377]

Le 23/01/2024 à 21:36, Harald Anlauf a écrit : Dear all, here's the second part of a series for the treatment of missing optional arguments passed to optional dummies, now fixing the case that the latter procedures are elemental. Adjustments were necessary when the missing dummy has the VALUE

Re: [PATCH] Fortran: passing of optional scalar arguments with VALUE attribute [PR113377]

Hello, Le 20/01/2024 à 22:58, Harald Anlauf a écrit : Dear all, here's the first part of an attempt to fix issues with optional dummy arguments as actual arguments to optional dummies. This patch rectifies the case of scalar dummies with the VALUE attribute, which in gfortran's argument

[PATCH] fortran: Restore current interface info on error [PR111291]

Hello, I tested this on x86_64-pc-linux-gnu without regression. There is no new test, as the problem is visible on an existing test with valgrind or an asan-instrumented compiler. OK for master? -- >8 -- This change is a followup to the fix for PR48776 (namely

Re: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

Hello, Le 30/11/2023 à 22:06, Harald Anlauf a écrit : the attached rather obvious patch fixes the first testcase of pr112772: we unconditionally generated copy-out code for optional class arguments, while the copy-in properly checked the presence of arguments. Regtested on x86_64-pc-linux-gnu.

Re: [PATCH] Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

Hello, Le 23/11/2023 à 22:59, Harald Anlauf a écrit : Dear all, the PR is about a redundant obsolescence warning for COMMON when a symbols appears in the scope of a submodule. As we did not warn for use-associated symbols, it seemed natural to extend this to symbols that are used in a

Re: [PATCH, testsuite, fortran] fix invalid testcases (missing MOLD argument to NULL)

Hello, Le 22/11/2023 à 22:02, Harald Anlauf a écrit : Dear all, testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid: NULL() is passed without MOLD to an assumed-rank dummy argument. This is detected by NAG, but not yet by gfortran (see pr104819). gfortran even ignores the MOLD

Re: [PATCH, v4] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Le 22/11/2023 à 21:36, Harald Anlauf a écrit : Hi Mikael! On 11/22/23 10:36, Mikael Morin wrote: (...) diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc index 2ac51e95e4d..be715b50469 100644 --- a/gcc/fortran/error.cc +++ b/gcc/fortran/error.cc @@ -980,7 +980,11 @@ char const

Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Le 21/11/2023 à 23:09, Harald Anlauf a écrit : Uhh, it happened again.  Attached a wrong patch. Only looked at the -v3 ...  My bad. Sorry! Harald On 11/21/23 22:54, Harald Anlauf wrote: Hi Mikael, Steve, On 11/21/23 12:33, Mikael Morin wrote: Harald, you mentioned the lack

Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

Hello, Le 20/11/2023 à 20:02, Steve Kargl a écrit : Harald, Sorry about delayed response. Got side-tracked by Family this weekend. On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote: On 11/19/23 01:04, Steve Kargl wrote: On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf

Re: [Patch] Fortran: Accept -std=f2023, update line-length for Fortran 2023

Le 17/11/2023 à 12:38, Tobias Burnus a écrit : Unless there are follow up comments, I will commit it later today. I skimmed quickly through the patch, and noticed one typo to fix: > diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi > index 10387e39501..5f87b330a22 100644 > ---

Re: [PATCH v2 0/3] libgfortran: empty array fixes

Le 07/11/2023 à 19:16, Harald Anlauf a écrit : Hi Mikael, this is OK. Thanks for the patches! Harald Patches pushed. Thanks for the (fruitful) review.

[PATCH v2 2/3] libgfortran: Remove early return if extent is zero [PR112371]

Remove the early return present in function templates for transformational functions doing a (masked) reduction of an array along a dimension. This early return, which triggered if the extent in the reduction dimension was zero, was wrong because even if the reduction operation degenerates to a

[PATCH v2 0/3] libgfortran: empty array fixes

://gcc.gnu.org/pipermail/fortran/2023-November/059896.html https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635305.html Changes from version 1: * Add patch 1/3 to the series fixing the unallocated empty result issue. * In patch 2/3 (formerly 1/2) clamp negative extent to zero. Mikael Morin (3

Re: [PATCH 2/2] libgfortran: Remove empty array descriptor first dimension overwrite [PR112371]

Le 06/11/2023 à 19:20, Harald Anlauf a écrit : Hi Mikael, Am 06.11.23 um 12:43 schrieb Mikael Morin: Remove the forced overwrite of the first dimension of the result array descriptor to set it to zero extent, in the function templates for transformational functions doing an array reduction

Re: [PATCH 1/2] libgfortran: Remove early return if extent is zero [PR112371]

Le 06/11/2023 à 19:12, Harald Anlauf a écrit : Hi Mikael, Am 06.11.23 um 12:43 schrieb Mikael Morin: Remove the early return present in function templates for transformational functions doing a (masked) reduction of an array along a dimension. This early return, which triggered if the extent

[PATCH 1/2] libgfortran: Remove early return if extent is zero [PR112371]

Remove the early return present in function templates for transformational functions doing a (masked) reduction of an array along a dimension. This early return, which triggered if the extent in the reduction dimension was zero, was wrong because even if the reduction operation degenerates to a

[PATCH 0/2] libgfortran: empty array fixes [PR112371]

Hello, while preparing a testcase, I encountered a bug which I filed as PR112371. Investigating further, I found two different problems which I propose to fix with the followup patches. Those have been bootstraped and regression tested on x86_64-pc-linux-gnu. OK for master? Mikael Mikael

Re: [PATCH] Improve tree_expr_nonnegative_p by using the ranger [PR111959]

Le 26/10/2023 à 11:29, Richard Biener a écrit : On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote: diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 40767736389..2a2a90230f5 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -15047,15 +15047,33 @@

Re: [PATCH] vec.h, v2: Make some ops work with non-trivially copy constructible and/or destructible types

Hello, Le 27/09/2023 à 12:46, Jakub Jelinek a écrit : --- gcc/vec.h.jj2023-09-27 10:38:50.635845540 +0200 +++ gcc/vec.h 2023-09-27 12:11:56.665586490 +0200 @@ -1028,13 +1050,17 @@ template inline void vec::truncate (unsigned size) { - gcc_checking_assert (length () >= size); +

[PATCH] fortran: Remove reference count update [PR108957]

Hello, Harald reminded me recently that there was a working patch attached to the PR. I added a documentation comment with the hope that it may help avoid making the same mistake in the future. Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Remove one reference count

[PATCH] fortran: Undo new symbols in all namespaces [PR110996]

Hello, this fixes a memory management issue in the fortran frontend. I have included the (reduced) testcase from the PR, even if it wasn't failing here on x86_64 with the test harness. Tested on x86_64-pc-linux-gnu and manually checked the testcase with valgrind. OK for master? -- >8 -- Remove

Re: [PATCH] fortran: Remove redundant tree walk to delete element

Le 08/09/2023 à 23:22, Harald Anlauf via Fortran a écrit : Am 08.09.23 um 12:04 schrieb Mikael Morin via Gcc-patches: Hello, this avoids some redundant work in the symbol deletion code, which is used a lot by the parser to cancel statements that fail to match in the end. I haven't tried

[PATCH] fortran: Remove redundant tree walk to delete element

Hello, this avoids some redundant work in the symbol deletion code, which is used a lot by the parser to cancel statements that fail to match in the end. I haven't tried to measure the performance effect, if any, on a pathological example; just passed the fortran testsuite on

Re: [PATCH] Fortran: runtime bounds-checking in presence of array constructors [PR31059]

Le 01/09/2023 à 22:48, Harald Anlauf a écrit : Hi Mikael, On 9/1/23 10:41, Mikael Morin via Gcc-patches wrote: May I suggest to handle functions the same way? I'll have a look at them, but will need to gather a few suitable testcases first. I have just opened PR111339 (https://gcc.gnu.org

[PATCH] diagnostics: Delete config pointer before overwriting it.

Hello, this is a fix for a small memory leak in the fortran frontend. Tested on x86_64-pc-linux-gnu, nothing stands out besides the apparently well-known guality instability. OK for master ? -- >8 -- Delete m_client_data_hooks before it is reassigned in tree_diagnostics_defaults. This fixes a

Re: [PATCH] Fortran: runtime bounds-checking in presence of array constructors [PR31059]

Le 31/08/2023 à 22:42, Harald Anlauf via Fortran a écrit : Dear all, gfortran's array bounds-checking code does a mostly reasonable job for array sections in expressions and assignments, but forgot the case that (rank-1) expressions can involve array constructors, which have a shape ;-) The

Re: [PATCH] fortran: Restore interface to its previous state on error [PR48776]

Le 28/08/2023 à 21:17, Harald Anlauf via Fortran a écrit : Hi Mikael, On 8/27/23 21:22, Mikael Morin via Gcc-patches wrote: Hello, this fixes an old error-recovery bug. Tested on x86_64-pc-linux-gnu. OK for master? I have only a minor comment: +/* Free the leading members

[PATCH] fortran: Restore interface to its previous state on error [PR48776]

Hello, this fixes an old error-recovery bug. Tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Keep memory of the content of the current interface body being parsed and restore it to its previous state if it has been modified at the time a parse attempt fails. This fixes memory errors

Re: [PATCH 0/3] fortran: fix length one character dummy args [PR110419]

Hello, Le 13/08/2023 à 23:16, Harald Anlauf via Fortran a écrit : Hi Mikael, Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches: Hello, (...) I have regression tested this on x86_64-unknown-linux-gnu, and powerpc64-unknown-linux-gnu (both -m32 and -m64). OK for master? this looks

[PATCH] dg-cmp-results: Escape slash from variant argument

Hello, I ran into a bug recently, running dg-cmp-results.sh with variant unix/-m32. This fixes it. OK for master? -- >8 -- Escape slash characters in $header variable (coming from the variant argument). This avoids runs with say "unix/-m32" as variant resulting in sed errors "unknown

[PATCH 3/3] testsuite: Use distinct explicit error codes in value_9.f90

Use distinct error codes, so that we can spot directly from the testsuite log which case is failing. gcc/testsuite/ChangeLog: * gfortran.dg/value_9.f90 (val, val4, sub, sub4): Take the error codes from the arguments. (p): Update calls: pass explicit distinct error codes.

  1   2   3   4   5   6   7   8   9   10   >