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.

[PATCH 1/3] fortran: New predicate gfc_length_one_character_type_p

Introduce a new predicate to simplify conditionals checking for a character type whose length is the constant one. gcc/fortran/ChangeLog: * gfortran.h (gfc_length_one_character_type_p): New inline function. * check.cc (is_c_interoperable): Use

[PATCH 2/3] fortran: Fix length one character dummy arg type [PR110419]

Revision r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa changed the argument passing convention for length 1 value dummy arguments to pass just the single character by value. However, the procedure declarations weren't updated to reflect the change in the argument types. This change does the

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

, and powerpc64-unknown-linux-gnu (both -m32 and -m64). OK for master? [1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html Mikael Morin (3): fortran: New predicate gfc_length_one_character_type_p fortran: Fix length one character dummy arg type [PR110419] testsuite: Use

Re: [COMMITTEDv3] tree-optimization: [PR100864] `(a&!b) | b` is not opimized to `a | b` for comparisons

Hello, Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit : diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc index a71c0727b0b..ddaf22f2179 100644 --- a/gcc/generic-match-head.cc +++ b/gcc/generic-match-head.cc @@ -121,3 +121,45 @@ bitwise_equal_p (tree expr1, tree

[PATCH 14/14] fortran: Pass pre-calculated class container argument [pr110618]

Pass already evaluated class container argument from gfc_conv_procedure_call down to gfc_add_finalizer_call through gfc_deallocate_scalar_with_status and gfc_deallocate_with_status, to avoid repeatedly evaluating the same data reference expressions in the generated code. PR fortran/110618

[PATCH 13/14] fortran: Use pre-evaluated class container if available [PR110618]

Add the possibility to provide a pre-evaluated class container argument to gfc_add_finalizer to avoid repeatedly evaluating data reference expressions in the generated code. PR fortran/110618 gcc/fortran/ChangeLog: * trans.h (gfc_add_finalizer_call): Add class container

[PATCH 09/14] fortran: Inline variable definition

The variable has_finalizer is only used in one place, inline its definition there. gcc/fortran/ChangeLog: * trans.cc (gfc_add_finalizer_call): Inline definition of variable has_finalizer. Merge nested conditions. --- gcc/fortran/trans.cc | 16 +++- 1 file changed, 7

[PATCH 10/14] fortran: Remove redundant argument in get_var_descr

get_var_descr get passed as argument both expr and expr->ts. Remove the type argument which can be retrieved from the other argument. gcc/fortran/ChangeLog: * trans.cc (get_var_descr): Remove argument ts. Use var->ts instead. (gfc_add_finalizer_call): Update caller. ---

[PATCH 08/14] fortran: Push final procedure expr gen close to its one usage.

Final procedure pointer expression is generated in gfc_build_final_call and only used in get_final_proc_ref. Move the generation there. gcc/fortran/ChangeLog: * trans.cc (gfc_add_finalizer_call): Remove local variable final_expr. Pass down expr to get_final_proc_ref and move

[PATCH 12/14] fortran: Factor scalar descriptor generation

The same scalar descriptor generation code is present twice, in the case of derived type entities, and in the case of polymorphic non-coarray entities. Factor it in preparation for a future third case that will also need the same code for scalar descriptor generation. gcc/fortran/ChangeLog:

[PATCH 05/14] fortran: Add missing cleanup blocks

Move cleanup code for the data descriptor after the finalization code as it makes more sense to have it after. Other cleanup blocks should be empty (element size and final pointer are just data references), but add them by the way, just in case. gcc/fortran/ChangeLog: * trans.cc

[PATCH 06/14] fortran: Reuse final procedure pointer expression

Reuse twice the same final procedure pointer expression instead of translating it twice. Final procedure pointer expressions were translated twice, once for the final procedure call, and once for the check for non-nullness (if applicable). gcc/fortran/ChangeLog: * trans.cc

[PATCH 00/14] fortran: Use precalculated class container for deallocation [PR110618]

and partially tested with RUNTESTFLAGS="dg.exp=*final*". The complete set has been fully tested on x86_64-pc-linux-gnu. OK for master? [1] https://gcc.gnu.org/pipermail/fortran/2023-July/059582.html [2] https://gcc.gnu.org/pipermail/fortran/2023-July/059583.html Mikael Morin (14): fortra

[PATCH 11/14] fortran: Outline virtual table pointer evaluation

gcc/fortran/ChangeLog: * trans.cc (get_vptr): New function. (gfc_add_finalizer_call): Move virtual table pointer evaluation to get_vptr. --- gcc/fortran/trans.cc | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git

[PATCH 04/14] fortran: Inline gfc_build_final_call

Function gfc_build_final_call has been simplified, inline it. gcc/fortran/ChangeLog: * trans.cc (gfc_build_final_call): Inline... (gfc_add_finalizer_call): ... to its one caller. --- gcc/fortran/trans.cc | 66 +--- 1 file changed, 25

[PATCH 02/14] fortran: Outline element size evaluation

gcc/fortran/ChangeLog: * trans.cc (get_elem_size): New function. (gfc_build_final_call): Outline the element size evaluation to get_elem_size. --- gcc/fortran/trans.cc | 44 ++-- 1 file changed, 30 insertions(+), 14 deletions(-)

[PATCH 03/14] fortran: Outline data reference descriptor evaluation

gcc/fortran/ChangeLog: * trans.cc (get_var_descr): New function. (gfc_build_final_call): Outline the data reference descriptor evaluation code to get_var_descr. --- gcc/fortran/trans.cc | 149 --- 1 file changed, 83 insertions(+),

  1   2   3   4   5   6   7   8   9   10   >