[Fix, fortran] PR84008 -ICE accessing kind and len parameters

Hi All, This 'obvious' fix has been pushed as r16-3648. Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index d51301aec44..bd0e6e9f540 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -5871,13 +5871,47 @@ gfc_resolve_subs

[Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar

Hi All, This patch corrects the current behaviour of gfortran to return arrays for type parameter references, when the designator is an array. It reuses existing code, as described in the ChangeLog. The necessary modification to pdt_20.f03 is a sufficient test. Regtests on FC42/x86_64. OK for mai

Re: [Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar

Paul On Sat, 6 Sept 2025 at 17:20, Jerry D wrote: > On 9/6/25 5:25 AM, Paul Richard Thomas wrote: > > Hi All, > > > > This patch corrects the current behaviour of gfortran to return arrays > > for type parameter references, when the designator is an array. It > >

Re: [Patch fortran] PR84432 & PR114815 - test for non-conforming default PDT initializers

Nit eradicated and pushed as r16-3590. Thanks Paul On Thu, 4 Sept 2025 at 21:53, Harald Anlauf wrote: > Hi Paul! > > Am 04.09.25 um 20:46 schrieb Paul Richard Thomas: > > Hi All, > > > > PDT components with default initializers must have type parameter and > &g

Re: [Patch, fortran] PR87362 - [PDT] ICE on variable declaration with undefined PDT parameter

Duly swung! Pushed as r16-3589. Thanks Paul On Thu, 4 Sept 2025 at 17:21, Jerry D wrote: > On 9/4/25 6:22 AM, Paul Richard Thomas wrote: > > Hi All, > > > > Although PR87362 is marked as fixed, the error becomes rather more > explicit with > > this patch,

[Patch fortran] PR84432 & PR114815 - test for non-conforming default PDT initializers

Hi All, PDT components with default initializers must have type parameter and length expressions that reduce to compile time integer constants. The chunk in expr.cc verifies that this is the case for array bounds and character lengths. This error checking results in pdt_26.f03 segfaulting because

[Patch, fortran] PR87362 - [PDT] ICE on variable declaration with undefined PDT parameter

Hi All, Although PR87362 is marked as fixed, the error becomes rather more explicit with this patch, which I actually developed for PR102457. Regtests on FC42/x86_64 - OK for mainline Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index 1e91b57

[Patch, fortran] PR87669 -Select type, incorrect handling of parameterized derived type

Hi All, The attached ChangeLogs explain the chunk in expr.cc. The chunk in is_extension_of was something of a surprise to me since I thought that we had stopped using the hash to identify derived types and to restrict their use to intrinsic types a long time ago. Using the vptr location is unambig

Re: [PATCH] Fortran: fix TRANSFER with rank 1 unlimited polymorphic SOURCE [PR121263]

Hi Harald, This is fine. The use of GFC_DECL_SAVED_DESCRIPTOR occurs all over the place and is necessitated by gfortran's handling of dummy arrays. I wonder how many other such cases are waiting out there? Thanks for the patch and to you, Jerry, for giving it a whirl. Paul On Tue, 2 Sept 2025

Re: [Patch, fortran] PR84432 - [F08] Detect illegal component initialization in pdt_27.f03

the noise. Paul On Tue, 2 Sept 2025 at 22:09, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This is another straightforward patch that detects variables with > non-integer type being used as PDT parameters. Note that much of the time, > when b

[Patch, fortran] PR84432 - [F08] Detect illegal component initialization in pdt_27.f03

Hi All, This is another straightforward patch that detects variables with non-integer type being used as PDT parameters. Note that much of the time, when being parsed, variable expressions have type BT_PROCEDURE and so the type of the symbol must be checked. The parameter fed to the PDT in pr95090

Re: [Patch, fortran] PR87669 -Select type, incorrect handling of parameterized derived type

ards Paul On Tue, 2 Sept 2025 at 18:13, Jerry D wrote: > On 9/2/25 4:43 AM, Paul Richard Thomas wrote: > > Hi All, > > > > The attached ChangeLogs explain the chunk in expr.cc. The chunk > > in is_extension_of was something of a surprise to me since I thought > t

[Patch, fortran] PR89707 - [F03] PDT with procedure pointer component

Hi All, This is another relatively straight forward PDT patch that enables typebound procedures with a parameterized kind specification for the interface. Regtests with FC42/x86_64. OK for mainline Paul PS Patches for PRs 84432, 103414 & 114815 are on the way. With all of the pending patches ap

Re: [Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

Pushed as r16-3481. Thanks for your help in getting it over the line! Paul On Sun, 31 Aug 2025 at 12:45, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald and Jerry, > > As it happens, I had done the regtesting, caught the failures of > value_opti

Re: [Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

> On 8/30/25 9:16 AM, Harald Anlauf wrote: > >> On 8/30/25 18:04, Jerry D wrote: > >>> On 8/30/25 8:04 AM, Paul Richard Thomas wrote: > >>>> Hi All, > >>>> > >>>> This patch is only a temporary fix because the chunks in trans

[Patch, fortran] PR99709 - [PDT] VALUE attribute for an object with nonconstant length parameter

Hi All, This patch is only a temporary fix because the chunks in trans-array.cc are representation dependent. As a whole, the patch is so straightforward that the ChangeLog serves as an explanation. Regtests with FC32/x86_64 - OK for mainline? Paul Change.Logs Description: Binary data diff --g

[Patch, fortran] PR82843 - (PDT) Constructors with PDT components do not work.

This patch corrects errors due to PDT components taking the PDT template as their type in PDT constructors and component references. The latter took a long time to debug because yours truly did not catch on to the basic problem until a light bulb moment, triggered by an excess of coffee :-) With th

[Patch, fortran] PR82205 - parametrized derived types, problems with initialization

This patch corrects the form of PDT constructors so that they are standard conforming: structure-constructor is type-name [ ( type-param-spec-list ) ] ( [ component-spec-list ] ) At present, the type-param-spec-list for PDTs is rolled into the component-spec-list. The patch separates the type-par

Re: [Patch, fortran] PR84122 redux - Incorrect statement sequence in PDT definition

Committed as r16-3308. Thanks, Jerry. Paul On Wed, 20 Aug 2025 at 19:27, Jerry D wrote: > On 8/20/25 8:54 AM, Paul Richard Thomas wrote: > > Hi Jerry, > > > > The attached patch fixes both pr84122 and pr85942. Beyond the more > > elaborate chunk in parse.cc,

Re: [Patch, fortran] PR84122 redux - Incorrect statement sequence in PDT definition

PDT object so that the type parameters do not appear. A few more parse errors will be fixed before I hit the representation of PDTs(pr82649). Cheers Paul On Tue, 19 Aug 2025 at 17:23, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, > > Thanks for taking a l

Re: [Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

!.. private by default !.. type data real(kind=k) :: m_a(c,r) end type mat_t Sorry about that. Thanks again Paul On Tue, 19 Aug 2025 at 17:13, Jerry D wrote: > On 8/19/25 4:15 AM, Paul Richard Thomas wrote: > > Hi All, > > > > I have just noticed that line

Re: [Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

Hi All, I have just noticed that line 9 in the testcase is not what was intended. It should read: integer, len, PUBLIC :: idim ! { dg-error "is not allowed" } and that the second dg-error should be removed. Paul On Tue, 19 Aug 2025 at 10:58, Paul Richard Thomas < paul.richard.tho

[Patch, fortran] PR84122 - Incorrect statement sequence in PDT definition

This is a trivial patch that enforces the requirement that PDT parameters do not have an access specification and appear before a PRIVATE statement within the derived type. Regtests on FC42/x86_64. OK for mainline? Paul diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc index 300a7a36fbd..d

[Patch, fortran] PR89092 - Host-associated generic used instead of use-associated TBP in call

The attached patch is utterly trivial. The only useful attribute that FooPrivate possesses to detect that it has been declared is 'subroutine'. This was missed in the attribute test in resolve.cc(was_declared). Adding it fixes the problem and regtests on FC42/x86_64. OK for mainline and some judi

Re: [Patch, fortran] PR121398 - gfortran rejects procedure binding on PDT

Thanks, Jerry. Pushed as r16-3135. Paul On Mon, 11 Aug 2025 at 18:38, Jerry D wrote: > On 8/11/25 8:10 AM, Paul Richard Thomas wrote: > > Hi All, > > > > This patch eliminates errors that arose in the use of generic bindings > in PDT > > templates and their inst

[Patch, fortran] PR121398 - gfortran rejects procedure binding on PDT

Hi All, This patch eliminates errors that arose in the use of generic bindings in PDT templates and their instances. This came about because none of the pdt instances matched the PDT template types and some of them might not match not match the containing specific type; ie. with different kind par

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Jerry et al., I attached an earlier version of the patch - apologies! Please find the latest attached. Paul On Thu, 7 Aug 2025 at 17:07, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Jerry, Steve and co., > > Thanks for the reviews. > > I have made

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

> With your updated patch addressing Steve's comments OK. > > We have time for minor tweaks if necessary. > > On 8/3/25 11:06 AM, Steve Kargl wrote: > > On Sun, Aug 03, 2025 at 12:20:24PM +0100, Paul Richard Thomas wrote: > > > > First, the easy one: >

Re: [PATCH 0/6] fortran: Remove isolated array descriptor fields updates

Hi Mikael, I feel sure that most of these updates result from ad hoc fixes to PRs that were completely fixed later on or are remnants of old fixes. Thanks for doing all this cleanup work. As you said in the second message, let's see how it pans out. The span field was initially introduced to dea

Re: [PATCH 0/3] fortran: Use existing setters and getters to access array descriptors

Hi Mikael, All three patches are OK for mainline. About half of the chunks I recognise and blames should point to me :-( Thanks for the patch. Paul On Sun, 3 Aug 2025 at 14:30, Mikael Morin wrote: > From: Mikael Morin > > The fortran frontend has getter and setter functions to generate code

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

important omission. Apart from the date, the ChangeLogs remain the same. OK for mainline? Paul On Tue, 29 Jul 2025 at 21:29, Harald Anlauf wrote: > Hi Paul! > > Am 24.07.25 um 08:07 schrieb Paul Richard Thomas: > > I forgot to include subroutine tests. Please find attached t

Re: [PATCH] fortran: Evaluate class function bounds in the scalarizer

Hi Mikael, The patch applies cleanly, regtests and fixes the problem, as advertised. It does likewise on 15-branch. Good for mainline and, I would suggest, backporting. Thanks for the patch. Paul On Wed, 30 Jul 2025 at 10:04, Mikael Morin wrote: > From: Mikael Morin > > This one may look l

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, That's exactly how I had a mind to do it. You beat me to it :-( Just get on, polish the patch and add more tests. Thanks Paul On Wed, 30 Jul 2025 at 15:53, Yuao Ma wrote: > Hi all, > > This patch introduces support for conditional expressions (also known as > ternary operators in s

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Anlauf wrote: > Hi Paul! > > Am 24.07.25 um 08:07 schrieb Paul Richard Thomas: > > I forgot to include subroutine tests. Please find attached the patch with > > updated testcases. > > > > Paul > > > > On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas &

Re: [PATCH 3/3] fortran: Consistently use the same assignment reallocation condition [PR121185]

Hi Mikail, Yes to this third patch as well. I haven't had time to track them down but there are other places where code has had to be inserted to prevent non-polymorphic references in a polymorphic way. I wonder if they cannot be unified at some time? All three can be pushed to mainline. Many th

Re: [PATCH 2/3] fortran: Trigger reference saving on pointer dereference [PR121185]

Hi Mikail, I apologise for the delay between reviewing this patch and the first. Some daytime work issues came up that I couldn't ignore. This addition is fine, does as advertised and is good for mainline. Thanks Paul On Sat, 26 Jul 2025 at 20:32, Mikael Morin wrote: > From: Mikael Morin >

Re: [PATCH 1/3] fortran: Bound class container lookup after array descriptor [PR121185]

Hi Mikael, This looks fine to me. OK for mainline. Thanks for the fix. Paul On Sat, 26 Jul 2025 at 20:31, Mikael Morin wrote: > From: Mikael Morin > > Regression-tested on x86_64-pc-linux-gnu. > OK for master? > > -- >8 -- > > Don't look for a class container too far after an array descript

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

I forgot to include subroutine tests. Please find attached the patch with updated testcases. Paul On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > The attached implements the F2018 generic statement, which has the same >

[Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi All, The attached implements the F2018 generic statement, which has the same semantics as the typebound version but can appear in any specification statement. As it says in the first comment in the patch, use is made of the existing, typebound matching functions to obtain access-spec and gener

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

ICE with new IMPORT feature

Dear All, The failure that Steve mentioned below is fixed. ChangeLogs and patch are self-describing. Regtests fine - OK for mainline? Paul On Sat, 12 Jul 2025 at 19:57, Steve Kargl wrote: > All, Paul, > > In testing Paul's recent addition of support for IMPORT, > I have uncovered an ICE due t

[Patch, fortran] PR121060 - ICE when argument is associate name created from type-bound operator result

At first this PR looked as if it was going to be one of those horrible typebound procedure/operator tangles. However, it turned out that this was entirely down to the attempt to extract the specific procedure for the ASSOCIATE name during parsing. Returning NULL before expression resolution fixed

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

Thanks, Jerry. Pushed as r16-2189. Note however that s/pr106135/pr106035 is required throughout. I will attend to it tomorrow. Paul On Mon, 23 Jun 2025 at 19:27, Jerry D wrote: > On 6/23/25 9:43 AM, Paul Richard Thomas wrote: > > Hello All, > > > > I was mulling ove

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

and the > dependencies in the build system have not been updated, because that is > what > the error message indicates. Can you try again? > > Because "works for me" using a clean build directory. How can I help you > further? > > Regards, > Andre > &

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Andre, All six patches require git apply --whitespace=fix --ignore-space-change < ~/prs/Shared_Memory/pr88076_v1_x.patch to apply. The build fails with: Makefile:3848: caf/.deps/caf_error.Plo: No such file or directory make[2]: *** No rule to make target 'caf/.deps/caf_error.Plo'. Stop. make

[Patch, fortran] PR106135 - Implement F2018 IMPORT statements

Hello All, I was mulling over the F2018 status of gfortran, when I came across the additions to the IMPORT statement. This seemed like such a useful addition to fortran that I set about an implementation; thinking that this would be low hanging fruit. Parsing and checking the constraints C897-8100

Re: [patch, Fortran] Fix PR 120139, missing asterisk on prototype with -fc-prototypes

Hi Thomas, Same remark as for PR120107! LGTM for both branches. Thanks Paul On Tue, 13 May 2025 at 21:30, Thomas Koenig wrote: > Hello world, > > this fixes the other regression which crept in with gfortran. > Again, regression-tested, plus the local testing script is > attached. > > Ok for

Re: [patch, Fortran] Fix 15/16 regression when non-interoperable types were dumped

Hi Thomas, I don't think that anybody else has been up to the job of hacking dejagnu to test patches to dump-parse-tree.cc :-) I think that the patch verges on the 'obvious' and is good for both 15-branch and mainline. Thanks for the patch. Paul On Tue, 13 May 2025 at 21:15, Thomas Koenig wr

Re: [patch, fortram] Bug 120049 - ICE when using IS_C_ASSOCIATED ()

HI Jerry, The patch looks good to me. OK for mainline and for backporting. I never quite know what to suggest for delaying backporting and so I will leave it to your judgement. Thanks for the patch. Paul On Tue, 6 May 2025 at 04:30, Jerry D wrote: > Attached patch fixes this by checking for

Re: [PATCH] Fortran: array subreferences and components of derived types [PR119986]

Hi Harald, This looks good to me both for mainline and backporting as far back as you wish. Thanks Paul On Sat, 3 May 2025 at 19:51, Harald Anlauf wrote: > Dear all, > > the attached, semi-obvious patch fixes bugging issues with passing of > array subreferences when either an inquiry referen

[Patch fortran] PR119948 - Source allocation of pure function result rejected

Committed as r16-329-g0abc77da9d704bba55a376bb5c162a54826ab94a following OK by Jerry on PR. I am ready to backport in a few weeks time if that is wanted. Regards Paul Fortran: Source allocation of pure function result rejected [PR119948] 2025-05-01 Paul Thomas gcc/fortran

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

Documentation for the REDUCE intrinsic

Hi All, Now that the reduce intrinsic seems to be OK on all platforms, I thought that it was time to catch up with the documentation. The attached produces good .html without any additional warnings or errors using texi2any and ~/share/info/gfortran.info is as intended. OK for mainline? Paul di

Re: [Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

Hi Andre, On Mon, 7 Apr 2025 at 07:29, Andre Vehreschild wrote: > Hi Paul, > > shouldn't this be done in iresolve.cc to make other parts of gfortran > benefit > from learning, that the sym is allocatable? > > I'll give it a try. I was attempting to eliminate any wider side effects by setting the

[Patch, fortran] PR119460 - gfortran.dg/reduce_1.f90 FAILs

Hi All, As far as I can tell, the attached patch fixes the problems with the reduce intrinsic. I would be grateful to the reporters if they would confirm that this is the case. The key to the fix appears in reduce_3.f90, which failed even with -m64. Although it was not apparent from the tree dump

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, 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

Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic

utable stack when working in > OpenCoarrays, but haven't had time (or desire) to look into it. I will put > myself into CC of the pr Jerry mentioned. > > Besides the mentions above, this looks good to me. > > Thanks for the patch and > > Regards, > Andre > &

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

[Patch, fortran] PR85836: Implement the F2018 reduce intrinsic

Hi All, This version of the REDUCE intrinsic patch has evolved somewhat since the posting on 2nd March. The most important changes are to the wrapper function and the addition of two testsuite entries. The wrapper function now effects: subroutine wrapper (a, b, c) type_of_ARRAY, inte

Re: [patch, changes.html] UNSIGNED, -fc-prototypes*, -Wexternal-interface-mismatch

Hi Thomas, It looks good to me. Thanks for the patch. Regards Paul On Sat, 15 Mar 2025 at 15:15, Thomas Koenig wrote: > Hello world, > > the attached patch, tested with "tidy -e", puts the two parts > mentioning UNSSIGNED into a single paragraph, mentions > extensions to -fc-prototypes and m

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

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

Re: [Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument

* ve...@gmx.de > > Am 6. Februar 2025 16:49:18 schrieb Paul Richard Thomas < > paul.richard.tho...@gmail.com>: > >> This regression must have been generated during my ASSOCIATE campaign; I >> am not sure when or where. Fortunately the fix is extremely simple and is >

[Patch, fortran] PR118750 - [14/15 Regression] ICE on associate with elemental function with polymorphic array dummy argument

This regression must have been generated during my ASSOCIATE campaign; I am not sure when or where. Fortunately the fix is extremely simple and is explained in the ChangeLog. Regression tests fine. OK for both affected branches? Paul Change.Logs Description: Binary data diff --git a/gcc/fortran

[Patch, fortran] PR118640 - [15 Regression] cp2k ICE in gfc_conv_expr_present since r15-5347

Hi All, Pushed as an 'obvious' one-liner(less additional comments) in r15-7224 Fortran: ICE in gfc_conv_expr_present w. defined assignment [PR118640] 2025-01-27 Paul Thomas gcc/fortran PR fortran/118640 * resolve.cc (generate_component_assignments): Make sure that the rhs temporary does not

Re: [Patch, fortran] PR96087 - [12/13/14/15 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575

;s just from reading the code, so if you think > that > can not happen, feel free to commit w/o the assert. > > Regards, > Andre > > On Wed, 22 Jan 2025 14:03:15 + > Paul Richard Thomas wrote: > > > Hi All, > > > > This patch fixes a double I

[Patch, fortran] PR96087 - [12/13/14/15 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575

Hi All, This patch fixes a double ICE arising from confusion between the dummy symbol arising from a module function/subroutine interface and the module procedure itself. In both cases, use of the name is unambiguous, as explained in the ChangeLog. The testcase contains both the original and the v

Re: [PATCH, RFC] Fortran: do not copy back for parameter actual arguments [PR81978]

Hi Harald, How did we miss that one for so long? This is certainly OK for mainline and, I would suggest, 14-branch. Thanks for the patch. Paul On Sun, 19 Jan 2025 at 20:42, Harald Anlauf wrote: > Dear all, > > this patch addresses a long-standing difference between gfortran and > other brand

[Patch, fortran] PR108434 - [12/13/14/15 Regression] ICE in class_allocatable, at fortran/expr.cc:5000

Hi Harald, hi all, As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name out of a total of 54 for fortran and libgfortran. It's time that some of these bugs are swatted, I think :-) As well as this PR, 106946 seems to have fixed itself and I have fixes for 102333 and 96087 w

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Hi Jerry, With such an illustrious group of contributors, I can hardly say 'no', can I? :-) It looks fine to me - OK for trunk. Regards Paul On Sun, 29 Dec 2024 at 23:10, Jerry D wrote: > Attached is the revised patch incorporating handling of optional > arguments of a calling procedure and

Re: [r15-6415 Regression] FAIL: gfortran.dg/coarray_lib_comm_1.f90 -Os scan-tree-dump-times original "_gfortran_caf_get_by_ct \\(caf_token.., 0B, 0B, 1, \\(unsigned long\\) atmp.[0-9]+.span" 4 on Linu

Hi Andre, It looks good to me. Thanks Paul On Mon, 23 Dec 2024 at 14:58, Andre Vehreschild wrote: > Hi all, > > I did an ooppsie with the patch for 107635. Attached is a patch that fixes > this. Essentially the regexp was to complicated for what was needed. So > now we > just count the numbe

[Patch, fortran] PR116254/118059 -[15 Regression] Bugs triggered by class_transformational_1/2.f90

Hi All, These bugs were tricky to find because neither were detected by regression testing on my platform. PR116254: This bug was sporadic even where the regression was detected. Richard Sandiford found "Conditional jump or move depends on uninitialised value" errors in the library, triggered by

[Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)

Hi All, This bug was so obviously in defiance of the standard that I pushed it to mainline as r15-6260. I meant to post this message immediately but was distracted before I could press send. I will be backporting today. Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/trans-ex

Re: [Patch, fortran] PR117797 - [13/14/15 Regression] ICE in gfc_get_array_span

ptr_size always the same > as a > descriptor->span? Can't the later be larger because of padding? If that is > the > case, then the first `else if (UNLIMITED...` you removed in > `gfc_get_array_span > ()` would return a larger number. > > Regards, > Andre

[Patch, fortran] PR117797 - [13/14/15 Regression] ICE in gfc_get_array_span

Hi All, This was yet another regression that I caused, which was backported and so I am rather anxious to fix it promptly. The modifications that I made to gfc_get_array_span caused unlimited polymorphic array components to be missed, when contained in a dummy. Instead, the dummy was taken to be

[Patch, fortran] PR117901 - [15 regression] class_transformational_1.f90 with -O3 and -fcheck=bounds gives ICE in make_ssa_name_fn

Hi All, This was a rather vexatious bug to track down and squash. I was led astray by the appearance of the bug in the tests for the implementation of intrinsic transformational functions with class arguments. It turns out to be an incipient bug in the handling of character(*) array associate name

[Patch, fortran] PR116261 - [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233

Hi All, I must apologise for reintroducing this regression again, after the second application of the fix for PR102689. I must admit that I had totally forgotten about it, even though it was the reason for withdrawing the patch the first time, and the failure was sporadic on my system, so I missed

Re: [Ping, Fortran, Patch, PR93158, v1] Fix ICE with coarrays on submodules

Hi Andre, The patch looks to be straightforward. OK for mainline. Thanks! Paul On Wed, 4 Dec 2024 at 12:16, Andre Vehreschild wrote: > Hi all, > > I figured this patch has not been okay'ed yet. Anyone in for a review? > > Regtests ok on x86_64-pc-linux-gnu / F39. Ok for trunk? > > Regards, >

Re: [Patch, fortran] PR102689 revisited - Segfault with RESHAPE of CLASS as actual argument

f you can reproduce the above, then please > open a separate PR to track this. Given what the patch resolves, > this is not a real show-stopper, so you may go ahead. > Committed as r15-5897. I will be following up with a new PR for the ICE. Thanks for the review. Paul > > Thanks,

Re: [patch, libgfortran] PR117820

Hi Jerry, That's fine for trunk and, after a decent interval, I would suggest that you backport to 14-branch. Please add the name of the contributor to the testcase unless you have been asked not to. Thanks Paul On Tue, 3 Dec 2024 at 04:13, Jerry D wrote: > Hi all, > > Attached patch adds a

Re: [Patch, fortran] PR102689 revisited - Segfault with RESHAPE of CLASS as actual argument

f90, and the chunks in > class.cc and resolve.cc). Can you please check? > > Cheers, > Harald > > Am 29.11.24 um 17:34 schrieb Paul Richard Thomas: > > Hi All, > > > > This patch was originally pushed as r15-2739. Subsequently memory faults > > were found an

[Patch, fortran] PR102689 revisited - Segfault with RESHAPE of CLASS as actual argument

Hi All, This patch was originally pushed as r15-2739. Subsequently memory faults were found and so the patch was reverted. At the time, I could find where the problem lay. This morning I had another look and found it almost immediately :-) The fix is the 'gfc_resize_class_size_with_len' in the ch

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

Hi Harald, > >> I'll wait until tomorrow to see if Paul intervenes. Otherwise I will >> proceed and push. >> > I succeeded in breaking things even more! Please proceed and push. Thanks Paul

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

Hi Harald and Jerry, I cannot see why the segfault is occurring of course: _gfortran_transfer_character_write (&dt_parm.9, &"line 4:"[1]{lb: 1 sz: 1}, 7); { struct array01_integer(kind=4) parm.10; integer(kind=8) D.4841; struct array01_intege

Re: [Patch, fortran] PR117768 - [15.0 regression] ICE in diagnostic_impl (?)

Pushed as r15-5716. Paul On Wed, 27 Nov 2024 at 09:15, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Andre, > > Yes indeed, I did regtest the patch :-) > > Thanks for the thumbs up. > > Paul > > > On Wed, 27 Nov 2024 at 09:07, An

Re: [Patch, fortran] PR117768 - [15.0 regression] ICE in diagnostic_impl (?)

patch. > > - Andre > > On Wed, 27 Nov 2024 08:57:25 + > Paul Richard Thomas wrote: > > > Hi All, > > > > The "fix" for PR84674 caused this regression. > > > > The diagnostics that I had used for PR117763 allowed me to find a much >

[Patch, fortran] PR117768 - [15.0 regression] ICE in diagnostic_impl (?)

Hi All, The "fix" for PR84674 caused this regression. The diagnostics that I had used for PR117763 allowed me to find a much better fix for PR84674 and so this patch reverts the chunk in resolve.cc. The chunk in class.cc works because non_overridable typebound procedures, whose parent is abstrac

Re: [PATCH] Fortran: fix minor front-end memleaks

Hi Harald, Looks good to me. Thanks Paul On Tue, 26 Nov 2024 at 19:51, Harald Anlauf wrote: > Dear all, > > the attached patch fixes two minor front-end memleaks I saw when working > on recent PRs (pr117774 is one of them) and running f951 under valgrind. > > Regtested on x86_64-pc-linux-gnu.

Re: [Bug fortran/84869] [12/13/14/15 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

Hi Harald, The pull said that the rebase was successful. Where that #define came from is a mystery to me. What do I do with it? Cheers Paul On Sun, 24 Nov 2024 at 21:26, Harald Anlauf wrote: > Am 24.11.24 um 17:40 schrieb Paul Richard Thomas: > > Fixed as 'obvious' on 13

Re: [patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

Hi Jerry, OK by me. A small nit: s/too/to/ in the ChangeLog. Thanks for the patch Paul On Mon, 25 Nov 2024 at 02:50, Jerry D wrote: > I would like to commit the attached patch for Steve. > > Regression tested on x86-64-linux-gnu. > > OK for trunk? > > Author: Steve Kargl > Date: Sun Nov

[Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

Hi All, The breakage was caused by the patch for PR109345. As it happens, this part of the patch was not required to fix the PR and looked to be a considerable simplification of the condition. Although correct that all is left are class dummies, it caused the regression by not checking that it is

[Bug fortran/84869] [12/13/14/15 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233

Fixed as 'obvious' on 13-branch to mainline with commit r15-5629-g470ebd31843db58fc503ccef38b82d0da93c65e4 An error with PR number in the mainline ChangeLogs will be corrected tomorrow. Fortran: Fix segfault in allocation of unlimited poly array [PR84869] 2024-11-24 Paul Thomas g

[Patch, fortran] PR84674(12-15 regression) and PR117730 - non_overridable typebound proc problems

Hi All, I was going through some of the older regressions and found pr84674, which was distinctly low hanging fruit because the contributor has found the offending bit of code. However, buried in this PR, on the grounds that it looked similar, was what has now become pr117730. This was quite diffi

Re: [Patch, fortran] PR109066 - Segfault when using defined assignment

Hi Thomas, This has to be the shortest interval between submission and pushing of a patch that I have experienced! Pushed to mainline as r15-5347... Thanks for the review! Paul On Sat, 16 Nov 2024 at 15:46, Thomas Koenig wrote: > Hi Paul, > > > > This is a particularly straightforward, goin

[Patch, fortran] PR109066 - Segfault when using defined assignment

Hi All, This is a particularly straightforward, going on 'obvious', patch. The bug goes back to at least gcc-6.4.1. OK for mainline and, after a week or two, to 13- and 14-branches? Regards Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc

Re: Fix type of malloc call in trans-expr.cc

Hi Jakub, Good catch! Does it fix any specific PR? If you don't have the time, I would be happy to apply the correction to 13-branch through to mainline. Regards Paul On Thu, 14 Nov 2024 at 22:24, Jakub Jelinek wrote: > On Thu, Nov 14, 2024 at 08:58:26PM +0100, Jan Hubicka wrote: > > fortra

[Patch, fortran] PR105054 - [12/13/14/15 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f

Hi All, The ChangeLog and comment make it clear what this patch does and why. OK for mainline and backporting after a week or so? Regards Paul diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 51e0af410c1..c54b3c85621 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolv

[Patch, fortran] PR116388 - [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

'Obvious' patch committed as r15-5078-g42a2df0b7985b2a4732ba1c29726ac7aabd5eeae. Will backport later Thanks to Tomas Trnka for investigating identifying the fix. Regards Paul

Re: [Patch, fortran] PR109345 - [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly

> > Hi Harald, > Thanks for the review! > ... except that the PR number should be corrected (109345 instead of > 109435) in the testcase and the commit message (Change.logs). > > Dyslexics of the world untie! Paul

  1   2   3   4   5   6   7   8   9   10   >