Re: [Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

Hi Paul, thanks for review. Committed as gcc-16-2372-g3a7fcf4f54e. The issue is also present on gcc-15 and 14. I would backport this to gcc-15 in a week, if no one objects! Thanks again, Andre On Fri, 18 Jul 2025 16:35:51 +0100 Paul Richard Thomas wrote: > Hi Andre, > > After a false

Re: [Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

Hi Andre, After a false start, the patch was applied to mainline, did what it was supposed to do and regtests fine. Ok for mainline. Thanks Paul On Fri, 18 Jul 2025 at 13:42, Andre Vehreschild wrote: > Hi all, hi Harald, > > attached patch fixes a runtime out-of-bounds error when an iterato

[Fortran, Patch, PR119106, v1] Allow iterator substitution in array constructors

Hi all, hi Harald, attached patch fixes a runtime out-of-bounds error when an iterator of an implied do-loop was not substituted as expected. The resulting code would still use the uninitialized iterator variable which then lead to out-of-bounds accesses. Harald, I did not look at the patch you p

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Le 09/07/2025 à 08:50, Andre Vehreschild a écrit : HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

On Wed, Jul 09, 2025 at 08:50:08AM +0200, Andre Vehreschild wrote: > > why shall the testcase be invalid? See the 2nd bullet in Fortran 2023, 9.7.1.3 Allocation of allocatable variables. An allocatable variable has a status of "unallocated" if it is not allocated. ... An allocata

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Am 09.07.25 um 08:50 schrieb Andre Vehreschild: HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to NU

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to NULL and the ubound below the lbound. Current gfortr

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Am 05.07.25 um 14:55 schrieb Mikael Morin: Hello Andre, I get a regression on this testcase with a patch that is otherwise regression-free. I think the testcase is invalid. It does:     type(container), allocatable :: list(:)     list = [list, new_elem(5)] so it's using the variable 'list

Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Hi Jerry, thanks for the review. Pushed as gcc-16-2086-gd1f05661fa6. Thanks again, Andre On Mon, 7 Jul 2025 10:49:50 -0700 Jerry D wrote: > On 7/7/25 8:39 AM, Andre Vehreschild wrote: > > Ping! > > > OK for mainline. > > Thanks, > > Jerry > > > > On Thu, 26 Jun 2025 15:32:47 +0

Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

On 7/7/25 8:39 AM, Andre Vehreschild wrote: Ping! OK for mainline. Thanks, Jerry On Thu, 26 Jun 2025 15:32:47 +0200 Andre Vehreschild wrote: Hi, I found a bug in the module cleanup expression at the end of the test. In the attached patch it is corrected. Regtests ok on x86_64-pc-linux

Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Ping! On Thu, 26 Jun 2025 15:32:47 +0200 Andre Vehreschild wrote: > Hi, > > I found a bug in the module cleanup expression at the end of the test. In the > attached patch it is corrected. > > Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > > Regards, > Andre > > On Wed, 25

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Hello Andre, I get a regression on this testcase with a patch that is otherwise regression-free. I think the testcase is invalid. It does: type(container), allocatable :: list(:) list = [list, new_elem(5)] so it's using the variable 'list' unallocated. The original testcase in the

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 4:12 PM, Jerry D wrote: On 7/2/25 9:40 AM, Jerry D wrote: On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

Hi Jerry, that is very odd, because the test timeout in Opencoarrays is set to 300 seconds at the max. (There are even smaller ones). I can reproduce the Opencoarray tests hanging for cmake build-type Release. On a Debug build they fail. I just repeated testing against OpenCoarrays. The gcc-15 br

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

Hi Jerry, thanks for the review and the ok. Committed as gcc-16-1967-g15413e05eb9. And special thanks for the kind words in the private mail you send me. It's very much appreciated that you even applied a translator to translate it to German. Thank you very much. I have set myself a reminder to

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 9:40 AM, Jerry D wrote: On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checki

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even using AI (haha

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On Wed, Jul 02, 2025 at 04:36:38AM -0700, Damian Rouson wrote: > git branch > gir checkout > git add > git commit > git rebase > git push > > It’s time to move beyond emailing patches! (Please.) I don't use git other than 'git clone', 'git reset --hard', and 'git diff'. If gfortran development

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

git branch gir checkout git add git commit git rebase git push It’s time to move beyond emailing patches! (Please.) Damian On Wed, Jul 2, 2025 at 03:17 Andre Vehreschild wrote: > Hi all, > > I successfully created a big mess with the previous patch. First of all by > applying an outdated one

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even using AI (haha) to figure if coranks of an expression have r

Re: [Fortran, Patch, PR120847 (was: PR120846), v1] Fix ICE when a function is called more than once in a coarray expression.

Hi Harald, thanks for review. Committed as gcc-16-1891-gee31ab9b195. Sorry for the typo in the email title. I should have proof read that before sending. I will set me a reminder to backport in a week to gcc-15. Thanks again, Andre On Mon, 30 Jun 2025 21:44:03 +0200 Harald Anlauf wrot

Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks

Hi Harald, thanks for the review. Committed as gcc-16-1885-g1b0930e9046. Will backport to gcc-15 in about a week. Thanks again. Regards, Andre On Mon, 30 Jun 2025 22:31:08 +0200 Harald Anlauf wrote: > Am 30.06.25 um 15:25 schrieb Andre Vehreschild: > > Hi all, > > > > here now the v

Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks

Am 30.06.25 um 15:25 schrieb Andre Vehreschild: Hi all, here now the version of the patch that seems to be more complete. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? This looks good to me. OK for both. Thanks for the patch! Harald Regards,

Re: [Fortran, Patch, PR120846, v1] Fix ICE when a function is called more than once in a coarray expression.

Am 30.06.25 um 15:29 schrieb Andre Vehreschild: Hi all, attached patch fixes an ICE when in an expression with a coindex a function was used more than once. E.g. coarray(mod( something ), mod( something else ))[i] ICE'd because a component for aliasing the second mod() could not be created. Reg

[Fortran, Patch, PR120846, v1] Fix ICE when a function is called more than once in a coarray expression.

Hi all, attached patch fixes an ICE when in an expression with a coindex a function was used more than once. E.g. coarray(mod( something ), mod( something else ))[i] ICE'd because a component for aliasing the second mod() could not be created. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for main

Re: [Fortran, Patch, PR120843, v2] Fix reject valid, because of inconformable coranks

Hi all, here now the version of the patch that seems to be more complete. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? Regards, Andre On Fri, 27 Jun 2025 15:44:20 +0200 Andre Vehreschild wrote: > I take this patch back. It seems to be incomp

Re: [Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

I take this patch back. It seems to be incomplete. - Andre On Fri, 27 Jun 2025 14:45:36 +0200 Andre Vehreschild wrote: > Hi all, > > this patch fixes a reject valid when the coranks of two operands do not match > and no coindex is given. I.e. when only an implicit this_image co-ref is used. >

[Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

Hi all, this patch fixes a reject valid when the coranks of two operands do not match and no coindex is given. I.e. when only an implicit this_image co-ref is used. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot d

Re: [Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Hi, I found a bug in the module cleanup expression at the end of the test. In the attached patch it is corrected. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Wed, 25 Jun 2025 15:48:11 +0200 Andre Vehreschild wrote: > Hi, > > Antony Lewis reported this

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Hi Harald, thanks for the review. Pushed all three parts as gcc-16-1698-g24940ad1534. A backport to gcc-15 of the first part of the patch, aka this one, seems to be feasible. I'd like to give the patch a bit time to mature here in gcc-16 and backport in about a week, when I do not forget it. Tha

Re: [Fortran, Patch, v1] 3/(3) Prevent creating tree that is never used.

Am 25.06.25 um 13:45 schrieb Andre Vehreschild: Hi, while hunting for pr120711 I found a construct where a call-tree was created and never used. The patch now just suppresses the tree creation and instead uses directly the tree that is desired. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for m

Re: [Fortran, Patch, v1] 2/(3) Stop spending memory in coarray single mode executables.

Am 25.06.25 um 13:42 schrieb Andre Vehreschild: Hi, attached patch prevents generation of a token component in derived types, when -fcoarray=single is used. Generating the token only wastes memory. It is never even initialized nor accessed. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainl

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Am 25.06.25 um 13:39 schrieb Andre Vehreschild: Hi all, attached patch fixes an out of bounds access in the clean up code of a concatenating array constructor. A fragment like list = [ list, something() ] lead to clean up using an offset (of the list array) that was manipulated in the loop cop

[Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

Hi, Antony Lewis reported this issue and also proposed a patch, that removes the was_finalized tracking. While this may lead to the desired effect for the issue at hand, I don't believe that the was_finalized tracking code has been there for no reason. This patch fixes the issue that also Antony

[Fortran, Patch, v1] 3/(3) Prevent creating tree that is never used.

Hi, while hunting for pr120711 I found a construct where a call-tree was created and never used. The patch now just suppresses the tree creation and instead uses directly the tree that is desired. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehresc

[Fortran, Patch, v1] 2/(3) Stop spending memory in coarray single mode executables.

Hi, attached patch prevents generation of a token component in derived types, when -fcoarray=single is used. Generating the token only wastes memory. It is never even initialized nor accessed. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild

[Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Hi all, attached patch fixes an out of bounds access in the clean up code of a concatenating array constructor. A fragment like list = [ list, something() ] lead to clean up using an offset (of the list array) that was manipulated in the loop copying the existing array elements and at the end po

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

Hi Harald, merged as gcc-16-1096-gafa2de8093a. Thanks again for the review. Regards, Andre On Tue, 3 Jun 2025 21:59:52 +0200 Harald Anlauf wrote: > Hi Andre, > > On 6/3/25 13:31, Andre Vehreschild wrote: > > Hi all, > > > > thanks for the explanations, Christophe. This is very much a

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

Hi Harald, I don't think it is necessarily the save attribute, but rather it's representation in "assembler". To my understanding the type's size is needed to allocate space in the .RSS or .data segment of the binary. To manage this the size needs to be compile time computable, which it is not

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

Hi Andre, On 6/3/25 13:31, Andre Vehreschild wrote: Hi all, thanks for the explanations, Christophe. This is very much appreciated. And sorry, I can't follow all presentations, conferences and publications. There is meanwhile way too much for me to process out there. Anyway, the regression I p

Re: [Fortran, Patch, PR120483, v2] Fix wrong type of saved allocatable strings.

Hi all, thanks for the explanations, Christophe. This is very much appreciated. And sorry, I can't follow all presentations, conferences and publications. There is meanwhile way too much for me to process out there. Anyway, the regression I produced in gomp should be fixed by the new version of p

Re: [Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

Hi! On Mon, 2 Jun 2025 at 20:53, Andre Vehreschild wrote: > > Hi Thomas, > > thanks for the ok. Unfortunately does the patch regress in gomp (test case > gomp/pr104382 when I am not mistaken ; the one with the lone 'save' > statement). This was reported by the regression testing host at first

Re: [Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

Hi Andre, attached patch fixes a missing substring ref on a saved allocatable string. The issue seems to be, that the variable is declared to be a character pointer and not a character array. When using the latter (why not), it works as expected and does not produce any regressions. Regtests o

Re: [Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

Hi Thomas, thanks for the ok. Unfortunately does the patch regress in gomp (test case gomp/pr104382 when I am not mistaken ; the one with the lone 'save' statement). This was reported by the regression testing host at first for arm, but also occurs on x86_64. Since when are proposed patches ch

[Fortran, Patch, PR120483, v1] Fix wrong type of saved allocatable strings.

Hi all, attached patch fixes a missing substring ref on a saved allocatable string. The issue seems to be, that the variable is declared to be a character pointer and not a character array. When using the latter (why not), it works as expected and does not produce any regressions. Regtests ok on

Re: [Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi Harald, thanks for the review. > this is bordering on the obvious and thus OK, except for: Well, it wasn't so obvious, when was able to add a mistake ;-) I have fixed that and committed as gcc-16-94-gcc2716a3f52. Thanks again for the review, Andre > > @@ -6967,7 +6972,8 @@ gfc_che

Re: [Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi Andre, Am 22.04.25 um 15:07 schrieb Andre Vehreschild: Hi all, attached patch fixes an illegal use of gfc_current_locus during the check()-phase of several coarray functions. Instead gfc_current_intrinsic_where needs to be used. this is bordering on the obvious and thus OK, except for: @@

[Fortran, Patch, PR119200, v1] Use correct locus while check()ing coarray functions.

Hi all, attached patch fixes an illegal use of gfc_current_locus during the check()-phase of several coarray functions. Instead gfc_current_intrinsic_where needs to be used. This error does not crash gfortran reliably. But valgrind reports an access to uninitialized memory. I therefore do not know

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

Hi Jerry, hi Paul, thanks for the review. Committed as gcc-16-79-g6e3b92848b5 (for the 6 of 5 commit) on mainline. Thanks again for the fast review. Regards, Andre On Fri, 18 Apr 2025 18:27:03 -0700 Jerry D wrote: > On 4/18/25 9:13 AM, Paul Richard Thomas wrote: > > Hi Andre, > > >

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 9:13 AM, Paul Richard Thomas wrote: Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request f

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild wrote: > Hi Jerry, > > thanks for the review and sorry for the long delay. With publishing the > team's > patches for gfortran, I also created a pull request for OpenCoarrays. > There I > was asked to add some testcase with more "beef" in

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 8:05 AM, Jerry D wrote: On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really ma

[Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support (was: Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support)

Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really makes use of teams and not only smoke tests it. T

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/13/25 11:47 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on gfc_error (

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on > gfc_error ( > "%s argument at %L must be a scalar %s vari

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/10/25 5:59 AM, Andre Vehreschild wrote: Hi all, I again have a series of patches. This time to improve the teams support in gfortran. 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of all TEAM statements. I wanted to prevent repeating myself over and over so I

[Fortran, Patch, Teams, 1/5] Unify handling of STAT= and ERRMSG= optional arguments [PR87939]

Hi all, this patch unifies handling of STAT= and ERRMSG= for some users of these optional arguments. The first introduction of the arguments seems to stem from SYNC, which choose the rule name sync_stat in the Fortran grammar. Therefore I named the structure and participating routines the same. Th

[Fortran, Patch, Team, 3/5] Update get_team, team_number and image_status to F2018 [PR88154, PR88960, PR97210, PR103001]

Hi all, attached patch reworks GET_TEAM(), TEAM_NUMBER() and IMAGE_STATUS() to adhere to the Fortran 2018 as much as possible and to play nicely with the previous patch of the TEAM statements. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild

[Fortran, Patch, Team, 4/5] Add team-support to this_image [PR87326]

Hi all, attached patch reworks the implementation of THIS_IMAGE() to adhere as much as possible to the Fortran 2018 standard. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From c6da27813d7a7622cae2663af7e25d21e

[Fortran, Patch, Team, 2/5] Improve F2018 TEAM handling [PR87326, PR87556, PR88254, PR103896]

Hi all, attached patch reworks (FORM|CHANGE|END|SYNC) TEAM to implement the Fortran 2018 as much as possible. This work has been done in sync with enhancing the OpenCoarrays library. Because CHANGE TEAM has an association list very similar to ASSOCIATE, the common code has been factored out to imp

[Fortran, Patch, Teams, 5/5] Add teams support in image_index and num_images for F2018

Hi all, attached patch reworks the NUM_IMAGES() implementation to adhere to the Fortran 2018 standard. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de From 1d0262dc068f4c6018d669a88387dbb7baaff39a Mon Sep 17 00:0

[Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

Hi all, I again have a series of patches. This time to improve the teams support in gfortran. 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of all TEAM statements. I wanted to prevent repeating myself over and over so I factored this out (DRY principle). Because the

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi all, the backport to gcc-14 has been committed as: gcc-14.2.0-996-gf955c5b409a Regards, Andre On Fri, 21 Mar 2025 13:33:37 +0100 Andre Vehreschild wrote: > Hi Paul, > > well, I had those might complicated patches bit my mightily. So let's hope for > the best :-) > > Thanks for the r

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

On 3/20/25 9:20 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a 15-regression where an element of an actual temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic dummy leads to a double free of the derived types components. This patch prevents this by preven

[Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi all, attached patch fixes freeing of procedure pointers that are stored in a derived type's component. GFortran did that already for polymorphic types but missed out on the others. Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email:

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Jerry, thanks for the review and the kind words. Committed as gcc-15-8481-g0f344846a62 Thanks again, Andre On Thu, 20 Mar 2025 11:42:35 -0700 Jerry D wrote: > On 3/20/25 9:20 AM, Andre Vehreschild wrote: > > Hi all, > > > > attached patch fixes a 15-regression where an element of an

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Andre, I am reasonably familiar with the mess that is gfc_conv_procedure_call :-) So in spite of you having a hard time explaining things today, I see your patch as verging on 'obvious' and is certainly the best that can be done without refactoring the whole thing. OK fo mainline. Thanks for

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi Paul, thanks for the (additional) review. The patch has been merged already as gcc-15-8481-g0f344846a62. But I totally agree, that conv_procedure_call is calling (pun intended) for a refactoring. Thanks again, Andre On Fri, 21 Mar 2025 14:34:13 + Paul Richard Thomas wrote: > Hi

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi Paul, well, I had those might complicated patches bit my mightily. So let's hope for the best :-) Thanks for the review. Committed with your proposed change in the testcase as gcc-15-8642-ga5c69abf138 Thanks again, Andre On Fri, 21 Mar 2025 10:40:11 + Paul Richard Thomas wrote:

Re: [Fortran, Patch, PR119380, v1] Fix freeing procedure pointers in components

Hi Andre, Gosh, that's a mighty complicated patch :-) I suggest changing the comment in the test case: s/Check that components of procedure pointer aren't freeed./Do not free procedure pointer components/ or some such. OK for mainline and, I propose, 14-branch. Regards and thanks Paul On Fri

[Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

Hi all, attached patch fixes a 15-regression where an element of an actual temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic dummy leads to a double free of the derived types components. This patch prevents this by preventing the deallocation of the array constructors

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Harald, thanks for the comments. > your solution looks basically correct to me, but I wonder why to > return early w/o error. Would the following logic be wrong? > > @@ -7349,7 +7357,8 @@ resolve_compcall (gfc_expr* e, const char **name) > gfc_symtree* target; > > /* Check that's real

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Harald and Paul, thanks for the reviews. Committed as gcc-15-8297-g9a13dc48a3a. Paul, I am working on the change team construct at the moment. It has an association list embedded. I will finish that work hopefully soon. After that it will be safe for you to "get out your notes and restart" w/o

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Andre and Harald, It looks good to me too. Indeed, the associate construct is a strange one since TKR guessing is done at a very early stage so that the associate block can be parsed. About a year ago, I started looking at tackling this by delaying parsing the blocks until the containing block

Re: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi Andre, Am 17.03.25 um 09:56 schrieb Andre Vehreschild: The issue is that the tbp (the typebound proc info structure) is not resolved completely when the associate tries to do an early resolve to determine the rank of the associate variable. When the expression to be resolved for that contains

[Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

Hi all, when Harald attached this PR to the associate meta-bug, I immediately thought: "Oh, this another one of these missing branches on ts.type == BT_CLASS thingies". Well, I was wrong. The issue is that the tbp (the typebound proc info structure) is not resolved completely when the associate t

Re: [Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi Harald, thanks for the review. Committed with the requested changes (intrinsic module ISO_FORTRAN_ENV and indexes -> indices in the description) as gcc-15-7997-gbaa9b2b8d2e I haven't added F2023 NOTIFY= image-selector yet, because at the moment I am striving to get F2018 more complete. Thanks

Re: [Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi Andre! Am 11.03.25 um 17:13 schrieb Andre Vehreschild: Hi all, attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed expressions. The patch also ensures that once in an image_selector_list no more regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is reje

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Harald and Jerry, thanks for taking the time to read my false assumptions ;-) The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer remapping is wrong. (F2018 §10.2.2.3 paragraph 9). The rhs is neither simply contiguous nor of rank one and therefore rejected. I spent some

[Fortran, Patch, PR98903, v1] Add parsing and code gen for TEAM_NUMBER in coindexes.

Hi all, attached patch adds parsing of TEAM_NUMBER= named arguments in coindexed expressions. The patch also ensures that once in an image_selector_list no more regular coarray indexes are accepted, i.e. coarray[1,2,3, STAT=S, 5] is rejected, because the 5 must not come after any of (STAT, TEAM, T

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Andre, Am 06.03.25 um 09:15 schrieb Andre Vehreschild: Hi Harald, I try to explain why I think my patch although solving the issue for this case, does not do so in every case: My patch lets dependency analysis figure that the two objects can not have any dependencies on each other or memory

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Harald, I try to explain why I think my patch although solving the issue for this case, does not do so in every case: My patch lets dependency analysis figure that the two objects can not have any dependencies on each other or memory they are pointing to when the types are different. Lets assu

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi Andre, Jerry already OK'ed your patch, but: Am 05.03.25 um 15:34 schrieb Andre Vehreschild: This fixes the PR, but not really the problem, because when say a obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't have a solution for that error. It might be needed to

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

On 3/5/25 6:34 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the =>

[Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

Hi all, attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the => had a derived type, independent of the actual

Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi Harald, thanks for the review. Committed as gcc-15-7826-g705ae582d51. The fix for pr107143 may be something similar. I am having a harder time getting a testcase correct, then fixing the gimplification fault (that's fixed, but the test is fouling me). Thanks again, Andre On Tue, 4 Ma

Re: [Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi Andre, Am 04.03.25 um 17:11 schrieb Andre Vehreschild: Hi all, attached patch fixes a gimplification fault when a pointer assignment to an allocatable array is done. The tree type is different, because of that flag in the lang_specific structure. View-converting the type fixes the issue. Re

[Fortran, Patch, PR104684, v1] Fix gimple error when pointer assigning alloc array.

Hi all, attached patch fixes a gimplification fault when a pointer assignment to an allocatable array is done. The tree type is different, because of that flag in the lang_specific structure. View-converting the type fixes the issue. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Reg

Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi Paul, thanks for the review. Committed as gcc-15-7812-g04909c7ecc0. Yes please: you do the backport. Thank you very much. I am looking at pr104684 at the moment, which is the last regression on my list (i.e. that I am assigned or cc'ed to). When the regression test for this is fine, I will co

Re: [Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi Andre, You beat me to it! I had just noticed the missing indirect reference. Yes, this is good for mainline and backporting to 14-branch at very least. Thanks for the patch. If you want to do the push to mainline, I will do the backporting if you like? I'll not be back at base for a little whi

[Fortran, Patch, PR103391, v1] Fix gimple error on assign to pointer array.

Hi all, attached patch fixes a 12-regression when an assignment to a pointer array is done. The issue was a missing indirect ref on assign as it was already done for allocatable arrays. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email

Re: [Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

Hi Steve, thanks for the review. Committed as gcc-15-7804-g5bd66483839. Thanks again, Andre On Mon, 3 Mar 2025 12:34:49 -0800 Steve Kargl wrote: > On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote: > > > > attached patches fix a 12-regression, when a caf token is reques

Re: [Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote: > > attached patches fix a 12-regression, when a caf token is requested from an > abstract class-typed dummy. The token was not looked up in the correct spot. > Due the class typed object getting an artificial variable for direct d

[Fortran, Patch, PR77872, v1] Fix ICE when getting caf-token from abstract class type.

Hi all, attached patches fix a 12-regression, when a caf token is requested from an abstract class-typed dummy. The token was not looked up in the correct spot. Due the class typed object getting an artificial variable for direct derived type access, the get_caf_decl was looking at the wrong decl.

Re: [Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi Paul, thanks for the review. Committed as gcc-15-7789-g43c11931acc. The regression is tagged as 15-regression only and was caused by PR fortran/90068. At least the change in trans-array.cc:2000-.. is one of major causes for that regression. Thanks again, Andre On Sat, 1 Mar 2025 08:0

Re: [Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi Andre, This looks fine to me. You say that this is a regression. How far back does it go? OK for mainline and, if required, for backporting. Thanks for the patch. Paul On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote: > Hi all, > > on this regression I had to chew a longer time. Ass

[Fortran, Patch, PR118747, v1] Prevent double free alloc. comp. in derived type function results

Hi all, on this regression I had to chew a longer time. Assume this Fortran: type T integer, allocatable:: a end type T result(type T) function bar() allocate(bar%a) end function call foo([bar()]) That Fortran fragment was translated to something like (pseudo code): T temp; T arr[]; temp

Re: [Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced

Hi Harald, thanks for the review. Committed as gcc-15-7747-gc1606e383a3. Thanks again, Andre On Thu, 27 Feb 2025 21:13:08 +0100 Harald Anlauf wrote: > Hi Andre, > > Am 27.02.25 um 18:36 schrieb Andre Vehreschild: > > Hi all, > > > > attached patch fixes user defined finalizers in deriv

Re: [Fortran, Patch, PR118730, v1] Ensure user-finalized type is referenced

Hi Andre, Am 27.02.25 um 18:36 schrieb Andre Vehreschild: Hi all, attached patch fixes user defined finalizers in derived (class) types not getting called, when the variable declared of that type was not used in the current block. The patch ensures calling the finalizer by marking the variable

  1   2   3   4   5   6   7   8   >