Re: [Patch, fortran] PR103312 - [11/12/13/14/15 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e

Hi Harald, You were absolutely right about returning 'false' :-) The patch is duly corrected. Committed to mainline and will be followed by backports in a few weeks. Regards Paul On Tue, 21 May 2024 at 19:58, Harald Anlauf wrote: > Hi Paul, > > Am 20.05.24 um 11:06 schrieb Pau

[Patch, fortran] PR103312 - [11/12/13/14/15 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e

Hi All, I don't think that this PR is really a regression although the fact that it is marked as such brought it to my attention :-) The fix turned out to be remarkably simple. It was found after going down a silly number of rabbit holes, though! The chunk in dependency.cc is probably more

[Patch, fortran] PR114874 - [14/15 Regression] ICE with select type, type is (character(*)), and substring

Hi All, I have been around several circuits with a patch for this regression. I posted one in Bugzilla but rejected it because it was not direct enough. This one, however, is more to my liking and fixes another bug lurking in the shadows. The way in which select type has been implemented is a

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

Hi Mikael, That is an ingenious solution. Given the complexity, I think that the comments are well warranted. OK for master and, I would suggest, 14-branch after a few weeks. Thanks! Paul On Sun, 12 May 2024 at 14:16, Mikael Morin wrote: > Hello, > > Here is my final patch to fix the ICE of

Re: [Patch, fortran] PR113363 - ICE on ASSOCIATE and unlimited polymorphic function

Hi Harald, Please find attached my resubmission for pr113363. The changes are as follows: (i) The chunk in gfc_conv_procedure_call is new. This was the source of one of the memory leaks; (ii) The incorporation of the _len field in trans_class_assignment was done for the pr84006 patch; (iii) The

Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

. A resubmission of the patch for PR113363 will follow since it depends on this one to fix all the memory problems. OK for mainline? Regards Paul On Thu, 9 May 2024 at 08:52, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald, > > The Linaro people caught that

Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

40 40 4 5$ > >abcdefghij^@^@^@^@^@^@^@^@^@^@<$ > > So since the physical representation of chr_a is sufficient > to hold star_a (F2023:16.9.212), no reallocation with a wrong > calculated size should happen. (Intel and NAG get this right.) >

[Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

This fix is straightforward and described by the ChangeLog. Jose Rui Faustino de Sousa posted the same fix for the ICE on the fortran list slightly more than three years ago. Thinking that he had commit rights, I deferred but, regrettably, the patch was never applied. The attached patch also fixes

Re: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

Hi Harald, Please do commit, with or without the extra bit for the function result. As well as having to get back to pr113363, I have patches in a complete state for pr84006 and 98534. However they clash with yours. You arrived at the head of the queue first and so after you :-) Regards Paul

Re: [PATCH] Fortran: fix issues with class(*) assignment [PR114827]

Hi Harald, This patch is verging on 'obvious', . once one sees it :-) Yes, it's good for mainline and all active branches, when available. Thanks Paul PS The fall-out pr114874 is so peculiar that I am dropping everything to find the source. On Mon, 29 Apr 2024 at 19:39, Harald Anlauf

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

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

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

Hi All, Could this be looked at quickly? The timing of this regression is more than a little embarrassing on the eve of the 14.1 release. The testcase and the comment in gfc_trans_class_init_assign explain what this problem is all about and how the patch fixes it. OK for 15-branch and

[Patch, fortran] PR93678 - [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures

Hi there, This regression turned out to be low hanging fruit, although it has taken four years to reach it :-( The ChangeLog says it all. OK for mainline and backporting after a suitable delay? Paul Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678] 2024-04-24 Paul

Re: [Patch, fortran] PR89462 - [11/12/13/14 Regression] gfortran loops in code generation

PS ignore the chunk in trans-array.cc. It is an attempt to fix PR93678 that literally did nothing. Paul On Wed, 24 Apr 2024 at 07:05, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi, > > The linaro pre-commit error testing picked up errors for arm and aarch &

Re: [Patch, fortran] PR89462 - [11/12/13/14 Regression] gfortran loops in code generation

more. Paul On Tue, 23 Apr 2024 at 16:25, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > Jakub pinpointed the source of this bug in comment 6 of the PR. The rest > was 'obvious' :-) > > I plan to push the patch to mainline in the next 24 hours unl

[Patch, fortran] PR89462 - [11/12/13/14 Regression] gfortran loops in code generation

Hi All, Jakub pinpointed the source of this bug in comment 6 of the PR. The rest was 'obvious' :-) I plan to push the patch to mainline in the next 24 hours unless there are opinions to the contrary. Backporting is proposed to occur a couple of weeks later. Best regards Paul Fortran: Generate

Re: [Patch, fortran] PR103471 - [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114

Hi Harald, > > the patch is OK, but I had to manually fix it. I wonder how you managed > to produce: > Yes, I had to use --whitespace fix when I reapplied it a few minutes ago. > > diff --git a/gcc/testsuite/gfortran.dg/pr93484.f90 > I had followed comment 1 in the PR and wrongly named the

[Patch, fortran] PR103471 - [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114

Hi All, This is a more or less obvious patch. The action is in resolve.cc. The chunk in symbol.cc is a tidy up of a diagnostic marker to distinguish where the 'no IMPLICIT type' error was coming from and the chunk in trans-decl.cc follows from discussion with Harald on the PR. Regtests fine. OK

[Patch, fortran] PR114739 [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458

This ICE was caused by my patch r14-9489-g3fd46d859cda10. However, the ICE hid a wrong error going back to at least 6.4.1 20180703. The patch fixes both and exposed incorrect error messages in existing tests in gfortran.dg. The fix for these was to add 'IMPLICIT NONE' in call cases so that there

[Patch, fortran] PR113363 - ICE on ASSOCIATE and unlimited polymorphic function

Hi All, This patch corrects incorrect results from assignment of unlimited polymorphic function results both in assignment statements and allocation with source. The first chunk in trans-array.cc ensures that the array dtype is set to the source dtype. The second chunk ensures that the lhs _len

[Patch, fortran] PR113956 - [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524

Patch pushed after pre-approval by Harald on Bugzilla. Fortran: Fix ICE in gfc_trans_pointer_assignment [PR113956] 2024-04-09 Paul Thomas gcc/fortran PR fortran/113956 * trans-expr.cc (gfc_trans_pointer_assignment): Remove assert causing the ICE since it was

[Patch, fortran] PR114535 - [13/14 regression] ICE with elemental finalizer

Hi All, This one is blazingly 'obvious'. I haven't had the heart to investigate why somebody thought that it is a good idea to check if unreferenced symbols are finalizable because, I suspect, that 'somebody' was me. Worse, I tried a couple of other fixes before I hit on the 'obvious' one :-(

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, It looks good to me. Noting that this is not a regression, OK for mainline on condition that you keep a sharp eye out for any associated problems. Likewise with backporting to 13-branch. Thanks Paul On Thu, 4 Apr 2024 at 02:34, Jerry D wrote: > Hi all, > > The attached log entry

[Patch, fortran] PR106999 [11/12/13/14 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

This regression has a relatively simple fix. The passing of a subroutine procedure pointer component to a dummy variable was being missed completely. The error has been added. Conversely, an error was generated for a procedure pointer variable but no use was being made of the interface, if one was

Re: [Patch, fortran] PR112407 - [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

Hi Harald, > > I had only a quick glance at your patch. I guess you unintentionally > forgot to remove those parts that you already committed for PR110987, > along with the finalize-testcases. > Guilty as charged. I guess I got out of the wrong side of the bed :-) > > I am still trying to find

[Patch, fortran] PR112407 - [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

Hi All, This bug emerged in a large code and involves possible recursion with a "hidden" module procedure; ie. where the symtree name starts with '@'. This throws the format decoder. As the last message in the PR shows, I have vacillated between silently passing on the possible recursion or

Re: [Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

Hi Harald, Thanks for the thumbs-up. Committed as 3c793f0361bc66d2a6bf0b3e1fb3234fc511e2a6. I will backport to 13-branch in a couple of weeks. Best regards Paul On Thu, 28 Mar 2024 at 22:27, Harald Anlauf wrote: > ...snip... > yes, this looks good here. > > ...snip... The patch looks

[Patch, fortran] PR110987 and PR113885 - gimplifier ICEs and wrong results in finalization

Hi All, The attached patch has two elements: (i) A fix for gimplifier ICEs with derived type having no components. The reporter himself suggested (thanks Kirill!): - if (derived && derived->attr.zero_comp) + if (derived && (derived->components == NULL)) As far as I can tell, this is the

Re: [PATCH] Fortran: no size check passing NULL() without MOLD argument [PR55978]

Hi Harald, This is completely fine - if you haven't committed, please do so. Thanks Paul On Fri, 22 Mar 2024 at 17:32, Harald Anlauf wrote: > Dear all, > > here's a simple and obvious patch for a rejects-valid case when > we pass a NULL() actual to an optional dummy for variants where >

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

Hi Mikael, This is very good. I am pleased to see global variables disappear and I like the new helper functions. As before, OK for mainline and, if you wish, 13-branch. Thanks Paul On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote: > This fixes a spurious invalid variable in specification

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

Hi Mikael, Sorry, I am replying to these in the order that they appear in my intray :-) OK for mainline and, if you wish, 13-branch. Thanks Paul On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote: > Hello, > > these patches correct diagnostics dealing with variables in specification >

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

Hi Mikael, This looks completely "obvious" to me. OK for mainline and, I would suggest, 13-branch. Thanks Paul On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote: > This fixes invalid undeclared fortran array bound variables > in the testsuite. > > gcc/testsuite/ChangeLog: > > *

Re: [PATCH] Fortran: fix IS_CONTIGUOUS for polymorphic dummy arguments [PR114001]

Hi Harald, This looks good to me. The testcase gives the same result with other brands. OK for mainline and for backporting. Thanks Paul On Tue, 12 Mar 2024 at 22:12, Harald Anlauf wrote: > Dear all, > > here's another small fix: IS_CONTIGUOUS did erroneously always > return .true. for

Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() )

s approach was very clever but has found it's limit with the associate construct. The sad thing is that this is the only blocker that I know of. Thanks Paul On Tue, 12 Mar 2024 at 21:07, Harald Anlauf wrote: > Hi Paul, > > On 3/12/24 15:54, Paul Richard Thomas wrote: > > Hi All,

Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() )

Hi All, This is the last posting of this patch before I push it. Harald is OK with it on the grounds that the inferred_type flag guards the whole lot, except for the chunks in trans-stmt.cc. In spite of Harald's off-list admonition not to try to fix everything at once, this version fixes most of

Re: [PATCH] Fortran: handle procedure pointer component in DT array [PR110826]

Hi Harald, This looks good to me. OK for mainline and, since it is so straightforward, for backporting. Thanks for the patch. Paul On Mon, 11 Mar 2024 at 21:20, Harald Anlauf wrote: > Dear all, > > the attached patch fixes an ICE-on-valid code when assigning > a procedure pointer that is a

Re: [PATCH] Fortran: error recovery while simplifying expressions [PR103707, PR106987]

Hi Harald, This all looks good to me. OK for mainline and, according to intestinal fortitude on your part, earlier branches. Thanks Paul On Tue, 5 Mar 2024 at 21:24, Harald Anlauf wrote: > Dear all, > > error recovery on arithmetic errors during simplification has bugged > me for a long

Re: [Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() )

/trans-stmt.cc:2383 > [...] > > I don't see anything wrong with it: NAG groks it, like Nvidia and Flang, > while Intel crashes at runtime. > > Can you have another brief look? > > Thanks, > Harald > > > On 1/6/24 18:26, Paul Richard Thomas wrote: > > These

[Patch, fortran PR89645/99065 No IMPLICIT type error with: ASSOCIATE( X => function() )

These PRs come about because of gfortran's single pass parsing. If the function in the title is parsed after the associate construct, then its type and rank are not known. The point at which this becomes a problem is when expressions within the associate block are parsed. primary.cc

Re: [PATCH] Fortran: fix argument passing to CONTIGUOUS, TARGET dummy [PR97592]

Hi Harald, It might be a simple patch but I have to confess it took a while for me to get my head around the difference between gfc_is_not_contiguous and !gfc_is_simply_contigous :-( Yes, this is OK for mainline and, after a short delay, for 13-branch. Thanks for the patch Paul On Sat, 16

{Patch, fortran] PR112834 - Class array function selector causes chain of syntax and other spurious errors

Dear All, This patch was rescued from my ill-fated and long winded attempt to provide a fix-up for function selector references, where the function is parsed after the procedure containing the associate/select type construct (PRs 89645 and 99065). The fix-ups broke down completely once these

Re: [PATCH] Fortran: allow RESTRICT qualifier also for optional arguments [PR100988]

Hi Harald, The patch is OK for mainline. Thanks Paul On Mon, 4 Dec 2023 at 22:47, Harald Anlauf wrote: > Dear all, > > the attached patch picks up an observation by Tobias that we did > not specify the RESTRICT qualifier for optional arguments even > if that was allowed. In principle this

Re: [PATCH] Fortran: fix TARGET attribute of associating entity in ASSOCIATE [PR112764]

Hi Harald, The original testcase is accepted by the two other brands to which I have access. OK for mainline and, I would suggest, 13-branch. Thanks Paul On Wed, 29 Nov 2023 at 21:16, Harald Anlauf wrote: > Dear all, > > the attached simple patch fixes the handling of the TARGET >

Re: [PATCH v2] Fortran: fix reallocation on assignment of polymorphic variables [PR110415]

Hi Andrew, This is OK by me. I attach a slightly edited version of the patch itself in the hope that it will make the code a bit clearer. Thanks and welcome! Paul On Mon, 27 Nov 2023 at 17:35, Andrew Jenner wrote: > This is the second version of the patch - previous discussion at: >

[Patch, fortran] PR112459 - gfortran -w option causes derived-type finalization at creation time

Hi All, Evidently -w causes gfc_option.allow_std to be set to default, which allows anything and everything to happen, including these f2003/8 finalizations. The fix is trivial. Regtests fine - OK for mainline and -13 branch? Paul Fortran: Prevent unwanted finalization with -w option

Re: [PATCH] Fortran: Fix generate_error library function fnspec

Hi Martin, This looks to be 'obvious' and is certainly OK for mainline. Backport if you wish. Thanks Paul On Fri, 3 Nov 2023 at 12:54, Martin Jambor wrote: > Hi, > > when developing an otherwise unrelated patch I've discovered that the > fnspec for the Fortran library function

Re: [PATCH] Fortran: passing of allocatable/pointer arguments to OPTIONAL+VALUE [PR92887]

Hi Harald, This looks good to me. OK for mainline. Thanks for the patch. Paul On Wed, 1 Nov 2023 at 22:10, Harald Anlauf wrote: > Dear all, > > I've dusted off and cleaned up a previous attempt to fix the handling > of allocatable or pointer actual arguments to OPTIONAL+VALUE dummies. > The

[Patch, fortran] PR112316 - [13 Regression] Fix for PR87477 rejects valid code with a bogus error...

Hi All, I have pushed as 'obvious' a fix for this regression to both 13-branch and mainline. The patch itself looks substantial but it consists entirely of the removal of a condition and repagination of the corresponding block. Please see below for part of my first comment on the PR for an

Re: [Patch, fortran] PR98498 - Interp request: defined operators and unlimited polymorphic

* gfortran.dg/interface_50.f90: New test. On Wed, 1 Nov 2023 at 20:12, Harald Anlauf wrote: > Hi Paul, > > Am 01.11.23 um 19:02 schrieb Paul Richard Thomas: > > The interpretation request came in a long time ago but I only just got > > around to implementing it. > > > > T

[Patch, fortran] PR98498 - Interp request: defined operators and unlimited polymorphic

The interpretation request came in a long time ago but I only just got around to implementing it. The updated text from the standard is in the comment. Now I am writing this, I think that I should perhaps use switch(op)/case rather than using if/else if and depending on the order of the

[Patch, fortran] PR64120

I found this 'obvious' fix, while going through PRs assigned to me. Regtests. OK for mainline? Cheers Paul Fortran: Allocatable automatic charlen must not be saved [PR64120]. 2023-10-31 Paul Thomas gcc/fortran PR fortran/64120 * trans-decl.cc (gfc_trans_deferred_vars): Detect automatic

[Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095

Bizarrely, since the fix for pr101625, the testcase compiles and runs correctly with s/select type (y => x)/select type (y => (x))/ ! The fix is straightforward and appears to be one of those wrinkles arising from the use of associate variables as a selector. The fault is reasonable since the

Re: [PATCH] Fortran: diagnostics of MODULE PROCEDURE declaration conflicts [PR104649]

Hi Harald, That's good for mainline. Thanks for the patch Paul On Thu, 26 Oct 2023 at 21:43, Harald Anlauf wrote: > Dear all, > > the attached patch improves the diagnostics of MODULE PROCEDURE declaration > conflicts, when one of the declarations is an alternate return. We used to > ICE

[Patch, fortran] PR104625 ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095

Hi All, The attached patch fixes the original problem, in which parentheses around the selector in select type constructs caused ICES. Stacked parentheses caused problems in trans-stmt.cc. Rather than tracking this down, the redundant parentheses were removed on resolution of the selector

Re: [Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types

> > you'll likely want > > ! { dg-do run } > > (Note the space before the dg-command.) > > Cheers, > Harald > > On 10/11/23 21:06, Harald Anlauf wrote: > > Hi Paul, > > > > On 10/11/23 10:48, Paul Richard Thomas wrote: > >> Hi All, >

[Patch, fortran] PR67740 - Wrong association status of allocatable character pointer in derived types

Hi All, The title line of the PR should have been changed a long time since. As noted in comment 5, the original problem was fixed in 10.5. This patch fixes the problem described in comments 4 and 6, where the hidden string length component was not being set in pointer assignment of character

[Patch, fortran] PR111674 - [13/14 regression] Failure to finalize an allocatable subobject of a non-finalizable type

This was fixed as 'obvious' with an off-list OK, posted on the PR, from Harald. Applied to 13-branch and trunk then closed as fixed. Cheers Paul Fortran: Alloc comp of non-finalizable type not finalized [PR111674] 2023-10-04 Paul Thomas gcc/fortran PR fortran/37336 PR fortran/111674 *

Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

Thanks for the fast review. > > > > Regards, > > Andre > > > > On Fri, 29 Sep 2023 13:38:57 +0100 > > Paul Richard Thomas wrote: > > > > > Hi Andre, > > > > > > Yes indeed - it's fine for trunk and, I w

Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

o is no problem. > > Regtests ok on x86_64_linux_gnu/f37. Ok for trunk? > > Regards, > Andre > > On Thu, 28 Sep 2023 19:21:12 +0100 > Paul Richard Thomas wrote: > > > Hi Andre, > > > > The patch looks fine to me. Since you mention it in the comment,

Re: [Fortran, Patch, Coarray, PR 37336] Fix crash in finalizer when derived type coarray is already freed.

Hi Andre, The patch looks fine to me. Since you mention it in the comment, is it worth declaring the derived type 'foo' in a module and giving it a final routine? Thanks for the patch. Paul On Thu, 28 Sept 2023 at 13:45, Andre Vehreschild via Fortran wrote: > > Hi all, > > attached patch

[Patch, fortran] PR68155 - ICE on initializing character array in type (len_lhs <> len_rhs)

Hi All, This is a straightforward patch that is adequately explained by the ChangeLog. Regtests fine - OK for trunk? Cheers Paul Fortran: Pad mismatched charlens in component initializers [PR68155] 2023-09-20 Paul Thomas gcc/fortran PR fortran/68155 * decl.cc (fix_initializer_charlen):

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

Hi Mikael, The comment is very welcome! Looks good to me. OK for mainline. Thanks for the patch. Paul On Fri, 15 Sept 2023 at 08:19, Mikael Morin via Fortran wrote: > > Hello, > > Harald reminded me recently that there was a working patch attached to the PR. > I added a documentation comment

Re: [PATCH] Fortran: improve bounds-checking for array sections [PR30802]

Hi Harald, The statement, in array_bound_check_elemental is redundant since the call is determined by a more restrictive condition. + if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)) +return; Apart from that, it looks good to me. OK for mainline. Thanks for the patch. Paul On Thu, 14

[Patch/fortran] PR87477 [meta-bug] [F03] issues concerning the ASSOCIATE statement

After two months on trunk, this has been backported: Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and

[Patch, fortran] PR92586 - ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

Committed as 'obvious'. 13-branch to follow. commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160 Author: Paul Thomas Date: Sat Aug 26 14:37:49 2023 +0100 Fortran: Supply a missing dereference [PR92586] 2023-08-26 Paul Thomas gcc/fortran PR fortran/92586

Re: [PATCH] Fortran: implement vector sections in DATA statements [PR49588]

Hi Harald, It all looks good to me and does indeed make the code clearer. OK for trunk. Thanks for the patch. I was shocked to find that there are 217 older bugs than 49588. Does anybody test older bugs to check if any of them have been fixed? Paul On Mon, 21 Aug 2023 at 20:48, Harald Anlauf

Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: > > Committed to trunk as 'obvious' in >

[Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

Committed to trunk as 'obvious' in r14-3098-gb8ec3c952324f866f191883473922e250be81341 13-branch to follow in a few days. Paul

Re: [PATCH] fortran: Release symbols in reversed order [PR106050]

Hi Mikhail, That's more than OK by me. Thanks for attacking this PR. I have a couple more of Steve's orphans waiting to be packaged up - 91960 and 104649. I'll submit them this evening.100607 is closed-fixed and 103796 seems to be fixed. Regards Paul On Tue, 11 Jul 2023 at 13:08, Mikael

[Patch, fortran] Fix default type bugs in gfortran [PR99139, PR99368]

The attached patch incorporates two of Steve's "Orphaned Patches" - https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html They have in common that they both involve faults in use of default type and that I was the ultimate cause of the bugs. The patch regtests with the attached testcases.

Re: [PATCH] Fortran: simplification of FINDLOC for constant complex arguments [PR110585]

Hi Harald, This is indeed obvious :-) Thanks for the patch. Paul On Fri, 7 Jul 2023 at 19:32, Harald Anlauf via Fortran wrote: > > Dear all, > > I intend to commit the attached obvious patch within 24h unless > someone objects. gfc_compare_expr() did not handle the case of > complex

Re: PR82943 - Suggested patch to fix

Hi All, I have gone through the PDT problem reports and made sure that they block PR82173. To my utter astonishment (i) There might be only one duplicate; and (ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of 50 PRs) depend on the representation. Regards Paul

Re: PR82943 - Suggested patch to fix

Hi Alexander, I suggest that you take a look at PR82649 before going too far down the road of fixing PDT bugs. This PR underlines just how wrong the PDT representation is - mea culpa! The mechanics for constructing PDTs are in decl.cc(gfc_get_pdt_instance). They need to be turned inside out to

Re: [Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression

; size of a character string you are using an intermediate > gfc_array_index_type, whereas I have learned to use > gfc_charlen_type_node now, which seems like the natural > type here. > > OK for trunk, and thanks for your patience! > > Harald > > > On 6/27/23 12:30

Re: [Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression

. (gfc_trans_subcomponent_assign): Expand assignment to class components to include intrinsic and character expressions. gcc/testsuite/ PR fortran/49213 * gfortran.dg/pr49213.f90 : New test On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote: > > Hi Paul! > > On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches

[Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression

Hi All, I was looking through Neil Carlson's collection of gfortran bugs and was shocked to find this rather fundamental PR. At 12 years old, it is certainly a "golden oldie"! The patch is rather straightforward and seems to do the job of admitting derived, intrinsic and character expressions to

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Hi Both, > while I only had a minor question regarding gfc_is_ptr_fcn(), > can you still try to enlighten me why that second part > was necessary? (I believed it to be redundant and may have > overlooked the obvious.) Blast! I forgot about checking that. Lurking in the back of my mind and going

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27 Thanks for the help and the review Harald. Thanks to Steve too for picking up Neil Carlson's bugs. Cheers Paul On Tue, 20 Jun 2023 at 22:57, Harald Anlauf wrote: > > Hi Paul, > > On 6/20/23 12:54, Paul Richard Th

Re: [Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

Committed as r14-2021-gcaf0892eea67349d9a1e44590c3440768136fe2b Thanks for the pointers, Tobias and Mikael, I used them both. Paul On Tue, 20 Jun 2023 at 21:47, Mikael Morin wrote: > > Le 20/06/2023 à 18:30, Tobias Burnus a écrit : > > On 20.06.23 18:19, Paul Richard Thomas via F

[Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

Dear All, This patch is verging on obvious. The PR was originally, incorrectly blocking PR87477 and the testcase has remained in my 'associate' directory. I thought that it is time to get shot of it! Is there a better way to detect a type(c_ptr) formal argument? Subject to advice on the

Re: [Patch] Fortran's gfc_match_char: %S to match symbol with host_assoc

Hi Tobias, This looks good to me. I'm interested to see it in use :-) OK for trunk Paul On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote: > > When just matching a symbol, one can use 'gfc_match_symbol (, host_assoc)' > and has the option to match with and without host association. > >

Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Hi Harald, Fixing the original testcase in this PR turned out to be slightly more involved than I expected. However, it resulted in an open door to fix some other PRs and the attached much larger patch. This time, I did remember to include the testcases in the .diff :-) I believe that, between

[Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault

Hi All, The attached patch is amply described by the comments and the changelog. It also includes the fix for the memory leak in decl.cc, as promised some days ago. OK for trunk? Regards Paul PS This leaves 89645 and 99065 as the only real blockers to PR87477. These will take a little while

Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement

wrote: > > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit : > >> Hi Harald, > >> > >> In answer to your question: > >> void > >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src) > >> { > >>free_expr0 (dest); > &g

Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement

of the expression and this was somehow connected with successfully simplifying the parentheses. Copying and replacing on no errors deals with the problem. Thanks Paul On Wed, 7 Jun 2023 at 19:38, Harald Anlauf wrote: > > Hi Paul! > > On 6/7/23 18:10, Paul Richard Thomas via Gcc-p

[Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement

Hi All, Three more fixes for PR87477. Please note that PR99350 was a blocker but, as pointed out in comment #5 of the PR, this has nothing to do with the associate construct. All three fixes are straight forward and the .diff + ChangeLog suffice to explain them. 'rankguessed' was made redundant

Re: [Patch, fortran] PR37336 finalization

Hi Thomas, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. I am dithering about changing the F2003/08 part of finalization since the default is 2018 compliance. That

Re: [PATCH, committed] Fortran: fix diagnostics for SELECT RANK [PR100607]

Hi Harald, It looks good to me. Thanks to you and Steve for the fix. I suggest that it is such and obvious one that it deserved back-porting. Cheers Paul On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran wrote: > > Dear all, > > I've committed that attached simple patch on behalf of

Re: [Patch, fortran] PR37336 finalization

Hi All, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Before that, I propose to remove the F2003/2008 finalization of structure and array constructors in 13- and 14-branches. I can see why it was removed from the standard in a correction to F2008

Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

aul Richard Thomas via Fortran a écrit : > > Hi All, > > > > This started out as the search for a fix to pr109948 and evolved to roll > in > > 5 other prs. > > > > Basically parse_associate was far too clunky and, in anycase, existing > > functions in resolve

[Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

Hi All, This started out as the search for a fix to pr109948 and evolved to roll in 5 other prs. Basically parse_associate was far too clunky and, in anycase, existing functions in resolve.cc were well capable of doing the determination of the target expression rank. While I was checking the

Re: [Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964

Duuh! There's even a choice :-) Paul On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote: > Hi Paul, > > On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > This problem caused the gimplifier failure because the reference chain > &g

[Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964

Hi All, This problem caused the gimplifier failure because the reference chain ending in an inquiry_len still retained a full array reference. This had already been corrected for deferred character lengths but the fix extends this to all characters without a length expression and integer

[Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE

Hi All, Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because this testcase checked that finalizable derived types could not be specified in a submodule. I have replaced the original test with a test of the patch. Thanks also to Malcolm Cohen for guidance on this. OK for

[Patch, fortran] PRs 105152, 100193, 87946, 103389, 104429 and 82774

Hi All, As usual, I received a string of emails on retargeting for PRs for which I was either responsible or was on the cc list. This time I decided to take a look at them all, in order to reward the tireless efforts of Richi, Jakub and Martin with some attention at least. I have fixed the PRs

Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings

assigning the value returned by gfc_conv_expr_descriptor. Also, guard the backend decl before testing with VAR_P. gcc/testsuite/ PR fortran/109451 * gfortran.dg/associate_61.f90 : New test On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald, &

Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings

Hi Harald, That's interesting - the string length '.q' is not set for either of the associate blocks. I'm onto it. Thanks Paul On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote: > Hi Paul, > > On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote: > > Hi All,

[Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings

Hi All, I think that the changelog says it all. OK for mainline? Paul Fortran: Fix some deferred character problems in associate [PR109451] 2023-04-07 Paul Thomas gcc/fortran PR fortran/109451 * trans-array.cc (gfc_conv_expr_descriptor): Guard expression character length backend decl

Re: [PATCH] Fortran: fix functions with entry and pointer/allocatable result [PR104312]

Hi Harald, The patch looks good to me - OK for mainline. Thanks Paul On Tue, 11 Apr 2023 at 21:12, Harald Anlauf via Fortran wrote: > Dear all, > > the testcase in the PR by Gerhard exhibited a mis-treatment of > the function decl of the entry master if the function result > had a pointer

Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement

PS Quite right about the allocation in PR93813 - consider it to be included. Cheers and thanks Paul On Fri, 7 Apr 2023 at 22:35, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald, > > Well done on noticing the memory leak :-) I have a fix for it tha

  1   2   3   4   5   6   7   8   9   10   >