[Patch, fortran] PR83746 - Errors using the max intrinsic in a PDT length parameter expression for a function result

This one was painfully obvious once I looked in the right place :-( Pushed to mainline as r16-3989. Paul Fortran: Intrinsic functions in PDT specification exprs. [PR83746] 2025-09-19 Paul Thomas gcc/fortran PR fortran/83746 * trans-array.cc (structure_alloc_comps): Add the pre and post bloc

[Patch, fortran] PR121948 - gfortran rejects structure constructor without (default) derived type parameter

Hi All, The recent change of PDT constructors to allow "structure-constructor is type-name [ ( type-param-spec-list ) ]( [ component-spec-list ] )" missed the possibility that the (type-param-spec-list) is optional, if default values are available. This patch permits this by looking for a left han

Re: [Patch, fortran] PR83763 - PDT dependency in assignment

Hi Jerry, Thanks for the review and testing. Pushed as r16-3851. As to the memory leak in pdt_3.f03, I will take a look at it this morning. I will raise a PR for it whatever I find. Regards Paul On Sun, 14 Sept 2025 at 20:14, Jerry D wrote: > > On 9/14/25 6:04 AM, Paul Richard Thomas

[Patch, fortran] PR83763 - PDT dependency in assignment

Hi All, The title in the PR is, "Bug 83763 - PDT variable sees content deallocated if variable is passed as an input to a function, and the function result is assigned to that same variable". The above is slightly more concise! The fix for the PR itself comprises the chunks in trans-expr.cc. On c

[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

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

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

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

[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] 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: 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

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

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

Following OK from Steve, with minor locus changes in access specification errors, pushed to mainline as r16-3099. Thanks for all the help with polishing the patch up to a good state. Paul On Thu, 7 Aug 2025 at 22:02, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Je

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: ICE with new IMPORT feature

Hi Steve, Your patch works as advertised. The second line in the error message receives the same dg-error line as the first, giving "# of expected passes 6". I'll push as soon as I get a chance - likely this afternoon. Thanks! Paul On Sat, 12 Jul 2025 at 19:57, Steve Kargl wrote: > All, Pau

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: GNU Fortran Compiler

Hello Rich, This list is devoted to the development and maintenance of gfortran. Please refer to the gfortran wiki https://gcc.gnu.org/wiki/GFortran for the information that you require. Please note that most Linux distributions offer up to date gfortran; eg. Fedora 42 has the latest release versi

Re: Execution time for gfortran regression testing

Hi Jerry, I have an octave script that does that. I last used it when I was working on ASSOCIATE. I'll dig it out and send it to you. Regards Paul On Fri, 13 Jun 2025 at 22:38, Jerry D wrote: > On 6/10/25 1:55 PM, Harald Anlauf wrote: > >> Gesendet: Mittwoch, 4. Juni 2025 um 20:37 > >> Von: "

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 15.0.1 treats "shiftl" as impure

Hi Christopher, I was somewhat surprised as well to find the pre-release version of gfortran in Fedora 42. sudo dnf install gcc14-gfortran.x86_64 will recover gfortran-14.2.1 for you, which is then invoked with: pault@fedora:~/prs/pr101047$ gfortran-14 --version GNU Fortran (GCC) 14.2.1 2025021

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

F2008 and F2018 statuses on gfortran wiki

Hi All, Recently a lot of work has been done on the "partial" or "no"s in the F2008 and F2018 implementation statuses. Please send me updates and I will do the editing in time for the gcc-15 release. Thanks Paul

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: Is ASSOCIATE implemented correctly in gfortran?

Hi Andre and Mikael, The associate block is added *after* the associate statement is matched and the associate_names added to the parent namespace; see parse.cc(parse_associate). nagfor and flang-new both behave in the same way as gfortran. So ifort and ifx are the odd ones out. In F2018 and F20

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: [COMMITTED] libgfortran/intrinsics: Fix build for targets with int32_t=long int

Hello Hans-Peter, Many thanks for that. The folk at Linaro posted a testsuite failure for the submitted patch. I corrected three of the casts but, as you found, somehow the fourth escaped me. Linaro notified me that the pushed version was failing and it was my intention to attend to that today. Yo

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: [Fortran, Patch, PR119272, v1] Fix handling of class' component call in associate

t; w/o producing > to > many merge conflicts. > > Thanks again and regards, > Andre > > On Wed, 19 Mar 2025 10:51:49 + > Paul Richard Thomas wrote: > > > Hi Andre and Harald, > > > > It looks good to me too. > > > > Indeed, the associat

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: F2018 REDUCE intrinsic

Hi Andre, Thanks for all these comments, aka early review: > > + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable > + || formal->sym->attr.pointer || formal->sym->attr.pointer > + || formal->sym->attr.optional || formal->sym->attr.optional > + || formal->sym->ts

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

F2018 REDUCE intrinsic

Hi All, This is very much an early version of the F2018 REDUCE intrinsic. I am posting it now because I have totally forgotten how to include new functions in libgfortran.so. -static-libfortran works fine and the results are the same as the other brands. At present, it produces several of link wa

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] PR115265 - Generic function for constructor not invoked for same-name derived type with procedure pointer component

Hi All, This PR was fixed by the patch for PR109066. I have had the attached testcase in my tree for more than a week now and I propose to push it tomorrow, unless there are any objections. The reporter has requested that the patch be backported. Neither PR is a regression and component defined a

[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

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

Andre > > On Tue, 10 Dec 2024 08:46:10 + > Paul Richard Thomas wrote: > > > 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 >

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

Hi Jerry, Thanks for the green light. I am holding off for 24 hours because I have a much cleaner solution in the offing. Cheers Paul On Mon, 2 Dec 2024 at 01:46, Jerry D wrote: > On 12/1/24 1:31 PM, Paul Richard Thomas wrote: > > Hi All, > > > > This is a regression c

[Patch, fortran]

Hi All, This is a regression caused by my patch for PR109345 - r15-5083. I overlooked the possibility that the unlimited polymorphic container might be the component of a dummy derived type. The fix is simple and relatively obvious. Regards Paul Fortran: Fix regression caused by r15-5083 [PR1

  1   2   3   4   5   >