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

Hi Andre, Yes indeed - it's fine for trunk and, I would suggest, 13-branch. Cheers Paul On Fri, 29 Sept 2023 at 11:01, Andre Vehreschild wrote: > > Hi Paul, > > thanks for the quick review. I've added a testcase with a module and a > finalizer in the derived type. This also is no problem. > >

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 fixes

[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): Ne

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 w

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 Sep

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

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

Re: beta gfortran 14.x.y (using -march=native and intrinsic repeat) gives a signal SIGILL

Hi Jorge, > There were some recent patches in this area IIRC. > > Jerry The tree dump is identical to mine, obtained with GNU Fortran (GCC) 14.0.0 20230809 (experimental), so I doubt that any recent patches are responsible. Being unable to reproduce the error, there is not much that I can do. S

Re: beta gfortran 14.x.y (using -march=native and intrinsic repeat) gives a signal SIGILL

I wonder why the development 14.0.0 doesn't exhibit this behaviour? Could you please rerun with the compile options -g -fdump-tree-original . The later should generate a file *.original with the content: void test () { character(kind=1) cc[1:32]; __builtin_memmove ((void *) &cc, (void *) &"

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 > r14-3098-gb8ec3c952324f866f191883473922e250be8134

[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 00/14] fortran: Use precalculated class container for deallocation [PR110618]

Hi Mikhail, That's ever so slightly embarrassing :-) My notes for that commit don't provide any enlightenment. Thanks Paul

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

Hi Mikael, I apologise for not being a bit faster with the review. I appreciate that you put a lot of effort into presenting the work in digestible chunks. Perhaps this is a personal perspective but I found it more difficult to absorb than reviewing a single patch. What do others think? That said

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

Hi Mikhail, This patch uses a field for gfc_se called class container, which is neither declared nor set as far as I can tell. Regards Paul On Thu, 13 Jul 2023 at 10:05, Mikael Morin via Fortran wrote: > > Pass already evaluated class container argument from > gfc_conv_procedure_call down to g

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

Hi Mikael, All 14 patches apply cleanly to trunk, which is rebuilding right now and will regtest this evening. I will review the composite patch tomorrow morning and will come back to you as soon as I can. At first sight all is well; perhaps the commented out line can be dispensed with? Many th

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 Morin

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

Hi Harald, I don't believe that a memory leak is possible since tmp is only non-null if it points to an existing symbol. I agree with you about the style but have to plead innocence because I am not the author :-) I will change it though. Thanks for the nit, Steve. Pushed as r14-2397-g9a2eab6172

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

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 cr

[Patch fortran] PR89645 - No IMPLICIT type error with: ASSOCIATE( X => function() )

This is a heads up for a patch that has not been exercised enough as yet. It works rather better and with less pain than I expected. The testcase is really that of PR99065 but I thought that I should give Ian Harvey prior credit for PR89645. Both appear in the meta-bug PR87477. I'll do the exerc

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

Hi Harald, I'll change to gfc_charlen_type_node. Thanks for your patience in reviewing this patch :-) Cheers Paul On Tue, 27 Jun 2023 at 20:27, Harald Anlauf wrote: > > Hi Paul, > > this is much better now. > > I have only a minor comment left: in the calculation of the > size of a character

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

Hi Harald, Let's try again :-) OK for trunk? Regards Paul Fortran: Enable class expressions in structure constructors [PR49213] 2023-06-27 Paul Thomas gcc/fortran PR fortran/49213 * expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer. * resolve.cc (resolve_assoc_var): Call gfc_is_

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

Hi Harald, I feel very foolish! You are absolutely right about gfc_is_ptr_fcn (gfc_expr *e). I never checked what gfc_expr_attr did here. I have fixed character (kind=4) but have now run into trouble with expressions such as cont = tContainer(sqrt (2.0_8)). I think that simplification is being mi

[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 Thomas via Gcc-patch

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 question

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 (&sym, host_assoc)' > and has the option to match with and without host association. > > How

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 t

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

Hi Harald, Well, at least you found the testcase :-) Thanks for pointing out the obvious; ie. that I had deviated from the original testcase. This is an important clue for some of the PRs that come up under the "select type flag". What is surprising is that it is gcc_assert (st->n.sym->assoc) tha

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

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

Morin 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

Hi Harald, In answer to your question: void gfc_replace_expr (gfc_expr *dest, gfc_expr *src) { free_expr0 (dest); *dest = *src; free (src); } So it does indeed do the job. I should perhaps have remarked that, following the divide error, gfc_simplify_expr was returning a mutilated version of

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

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 s

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 Steve

Re: A doubt about IMPORT and SELECT TYPE

Hi Steve, As noted in the previous email :-), although I didn't mention the partially cooked patch. One day, once F2003 is sorted, I might turn to F2008/18! Cheers Paul On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran, wrote: > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richar

Re: A doubt about IMPORT and SELECT TYPE

Hi Jorge, PRs 108650/106035 cover this problem. Thanks Paul On Fri, 2 Jun 2023 at 15:04, Jorge D'Elia via Fortran wrote: > > Hi, > > I have a doubt about IMPORT and SELECT TYPE, please see the > forwarded message below (that also has a sample code), as well > > https://www.ibm.com/docs/en/xffb

Re: A doubt about IMPORT and SELECT TYPE

Hi Jorge, As I posted in the Intel Community, the error generated by gfortran (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) The IMPORT statement is allowed only in an interface-body. Could you please raise a problem report in gcc Bugzilla? Thanks Paul On Fri, 2 Jun 2023 a

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 comm

Re: Possible funding of gfortran work

Hi Andre, It's good to hear from you. I would suggest the following: (i) Complete F2003 compliance - Now that finalization is within a whisker of compliance, this mostly leaves putting PDTs right. The framework is all there, it just needs revamping. I can provide guidance or a statement of work h

Re: Building Legacy Code and Intel Libraries

Hi Larry, The last time I had to deal with this I removed the offending use statements, as suggested in the thread pointed to by Andrew, and then searched for the missing references by name. All were easily replaced by intrinsic procedures. Good luck Paul On Wed, 17 May 2023 at 21:23, Andrew P

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 > > ending in an inquiry_len still retain

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

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

Re: finalization issue

Hi Steve, Nagfor responds to the test case with "Error: pr97122.f90, line 14: Type T has final subroutines but is not defined in the specification part of a module" F2018: "C787(R753) A final-subroutine-name shall be the name of a module procedure with exactly one dummy argument." Since, of nece

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

[Bug fortran/104272] finalizer gets called during allocate

Hi Harald, Committed with the coding error that you spotted put right. commit r13-7181-gb0e85485fbf042abccee5c0a9eb499da386c8db3 I will build up a composite finalization patch for 12-branch in the coming days. However, I still have one of Andrew Benson's bugs to put right before I do that. Rega

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

Hi Harald, The fix was trivial. An updated patch and testcase are attached. Thanks Paul Fortran: Fix some deferred character problems in associate [PR109451] 2023-04-14 Paul Thomas gcc/fortran PR fortran/109451 * trans-array.cc (gfc_conv_expr_descriptor): Guard expression character length

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, > > > > I think that the c

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

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 at

Re: [committed] gfortran.dg/gomp/affinity-clause-1.f90: Fix scan-tree-dump (was: [r13-7120 Regression] FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times original "#pragma omp task a

Hi Tobias, I started applying my poor knowledge of regular expressions to fix this last night and timed out. Thanks for doing it for me. I will look carefully and learn from the master :-) Is it really a regression, when a change exposes a latent bug? Never mind, though, it's fixed. Cheers Paul

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 that I was > going to post

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

Hi Harald, Well done on noticing the memory leak :-) I have a fix for it that I was going to post separately. Actually, it is a trivial one liner, which I could include with the patch. @@ -2554,23 +2559,25 @@ gfc_conv_string_length (gfc_charlen * cl, gfc_expr * expr, stmtblock_t * pblock) e

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

duuuh! Please find them attached. Thanks Paul On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: > Hi Paul, > > I don't see the new testcases. Is this an issue on my side, > or did you forget to attach them? > > Thanks, > Harald > > On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote:

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

Dear All, Please find attached a slightly updated version of the patch with a consolidated testcase. The three additional testcases are nothing to do with associate and test fixes of character related bugs. OK for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-

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

o be rife! > > Cheers > > Paul > > > On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote: > >> Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: >> > Hi All, >> > >> > I have made a start on ASSOCIATE issues. Some of the low(-ish

Re: [Patch, fortran] PR104272 - finalizer gets called during allocate

Hi Harald, Quite right - good spot. There was an 'else' that turned out to be unnecessary. Thanks Paul On Wed, 5 Apr 2023 at 19:50, Harald Anlauf wrote: > Hi Paul, > > On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > This is a first in my recent experience - a

[Patch, fortran] PR104272 - finalizer gets called during allocate

Hi All, This is a first in my recent experience - a very old bug that produces too many finalizations! It results from a bit of a fix up, where class objects are allocated using the derived typespec, rather than a source or mold expression. This occurs upstream in resolve.cc, where the default ini

Re: [PATCH] Fortran: reject module variable as character length in PARAMETER [PR104349]

Hi Harald, OK for mainline. It is sufficiently small that, if there is any fallout in the next weeks, it can easily be reverted without great impact. Thanks for the patch. Paul On Mon, 3 Apr 2023 at 20:46, Harald Anlauf via Fortran wrote: > Dear all, > > the attached patch fixes an ICE-on-in

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

ote: > Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: > > Hi All, > > > > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging > > fruit are already fixed but I have yet to check that they a really fixed > > and to close them: > &

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

Hi All, I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging fruit are already fixed but I have yet to check that they a really fixed and to close them: pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338 The attached patch picks up those PRs involving de

Re: [PATCH, commited] Fortran: remove dead code [PR104321]

Hi Harald, If you will excuse the British cultural reference, that's a Norwegian Blue alright! Good spot. OK for mainline. Thanks Paul On Sat, 25 Mar 2023 at 19:13, Harald Anlauf via Fortran wrote: > Dear all, > > I've committed the attached patch from the PR that removes > a dead code snip

Re: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

Hi Harald, This is good for trunk and for backporting. Thanks for the rapid fix. Paul On Mon, 20 Mar 2023 at 20:57, Harald Anlauf via Fortran wrote: > Dear all, > > the attached trivial patch catches a MODULE PROCEDURE outside of a > module interface before we run into an internal error. > >

Re: [patch, fortran, doc] Explicitly mention undefined overflow

Hi Thomas, Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? Thanks for the doc patches! Paul On Sun, 19 Mar 2023 at 08:32, Thomas Koenig via Fortran wrote: > Here's also an update on the docs t

[Patch, fortran] PR87127 - External function not recognised from within an associate block

Hi All, I committed this to 8-branch on 2019-04-24 but not to 9-branch. I have no record of why I did this. The patch now requires an additional line, && sym->ns->proc_name->attr.proc != PROC_MODULE to prevent the error message in pr88376.f90 from changing to the less helpful Error: Speci

Re: [patch, wwwdocs] Mention finalization

Hi Thomas, Thanks for that! I think that your one-liner says it all :-) There are three PRs left open that PR37336 depends on: PR65347: Is partially fixed. The F2003/8 feature of finalization of a structure constructor within an array constructor doesn't work. I wonder if a compile option -finali

Re: [Patch, fortran] PR37336 finalization

Thank you, Richard. I am planning to commit either very late tonight, Friday night or early on Saturday morning to avoid any interference by other commits. It will take me a little while to get it done and so I want to reduce the probability of a mid-air collision. Best regards Paul >

Re: [Patch, fortran] PR37336 finalization

Hi All, I am awaiting a green light to commit this patch or not. Cheers Paul On Fri, 10 Mar 2023 at 16:49, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Thomas, > > Before answering that, I thought that I had better try the polyhedron > suite with -fwrapv and -std=legac

Re: [Patch, fortran] PR37336 finalization

Hi Thomas, Before answering that, I thought that I had better try the polyhedron suite with -fwrapv and -std=legacy together. As far as I can see, all is well and so, yes, I think that is a good idea. Cheers Paul D

Re: [Patch, fortran] PR37336 finalization

g wrote: > > > On 08.03.23 15:55, Paul Richard Thomas via Fortran wrote: > > > As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but > > > runs successfully at -O2. > > > > I can confirm that. > > > > > I presume that this is a ser

Re: [Patch, fortran] PR37336 finalization

Hi Tobias, I agree completely with all that you are saying. Declaring derived types in a module is guaranteed to produce vtables and final wrappers, so that they are available in scopes where they are used. Had we thought more about class design, we might have added the vtable to the entity, rathe

Re: [Patch, fortran] PR37336 finalization

Hi All, I ran the polyhedron testsuite with the patched gfortran-13.0.1 and 7.4(as used in the posted Linux test). The timings are comparable except for rnflow.f90. As noted below, rnflow.f90 hangs with the unpatched mainline at -O3 but runs successfully at -O2. I presume that this is a serious

Re: [Patch, fortran] PR37336 finalization

Hi Richard, Smart pointer applications really torture finalization. That's why Andrew and Salvatore's help has been so much appreciated. I haven't run the polyhedron suite for some little while and so I just downloaded it. I ran into a significant problem with the harness. The binary segfaulted b

Re: [Patch, fortran] PR37336 finalization

The alternative is that the patch be reviewed and committed as it is. I have been neglecting my daytime job to get to this point and must spend some time catching up. Cheers Paul On Wed, 8 Mar 2023 at 08:05, Thomas Koenig wrote: > Hi Paul, > > > Last night, I scoped out the work required to g

Re: [Patch, fortran] PR37336 finalization

Hi Thomas and Steve, Last night, I scoped out the work required to get the patch ready to commit. Sorting out the testcases will be the main load since they have grown "organically". I propose to change over to one test for each paragraph of F2018 7.5.6.2/7.5.6.3 and to verify them against the oth

Re: [PATCH] Fortran: fix ICE in check_charlen_present [PR108420]

Hi Harald, This is fine for mainline and for backporting if you feel so inclined. Thanks for the patch. Paul On Mon, 16 Jan 2023 at 21:12, Harald Anlauf via Fortran wrote: > Dear all, > > it appears that the fix for pr107874 uncovered a latent bug > for the case of arrays of type character a

Chained modules in a testcase

Hi, Andrew Benson found a rather horrible bug in my finalization patch that involved two separate module files and another containing both a module and the main program. They must be compiled separately for the bug to appear. This bug arises in finalization because some derived type function resul

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Thomas, I was thinking of a function in resolve.cc, similar to generate_component_assignments that would generate the final call and, where necessary, generate a temporary and place rhs finalization after the assignment. Since this would only involve ordinary assignment and subroutine calls, I

Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)

Hi Thomas, Following your off-line explanation that the seemingly empty looking assembly line forces an effective reload from memory, all is now clear. OK for mainline and for backporting as you see fit. Thanks for the patch. Paul On Sat, 7 Jan 2023 at 15:46, Thomas Koenig via Fortran wrote:

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Thomas, What causes the ICES? Cheers Paul On Sat, 7 Jan 2023 at 15:28, Thomas Koenig wrote: > Hi Paul, > > first, thanks for taking on this rather monumental task! > > > Given the scale of the overall patch, I am beginning to have a lot of > > sympathy with Thomas's suggestion that the fi

Re: Fw: Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi All, Please find attached a patch for trans-array.cc that does what Harald suggests; ie. finalization of array and structure constructors only occurs with -std=f2003/8. Two versions of finalize_38.f90 are attached. One which tests -std=gnu/f20018 and the other -std=f2008. Frankly, I think that

Re: [PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]

Hi Harald, Thanks for doing that. My attention is elsewhere gfortran-wise. Good for mainline. Paul On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran wrote: > Dear all, > > I am submitting the attached simple - and obvious - patch on > behalf of Paul. It prevents a resource exhaustion d

Re: Team Collaboration Considerations

Hi Jerry and everybody else, I am with Tobias on this. Between work, gfortran, RSPCA, club and neighbourhood activities I am "channelled" up to the eyeballs. Adding another wouldn't make any great odds but I couldn't pay much more attention to it than many of the others - sorry! At the present, I

Re: Quick question...

Hi Gary, The equally quick answer is that I don't know. https://help.imsl.com/fortran/ indicates that the library is compiled with Intel fortran. While there are fortran 77 interfaces for most (all?) of the routines, all the examples show use of modules that will have been compiled with Intel. I s

Re: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR [PR107870]

Hi Harald, You will, perhaps, rue having me back when you see the updated finalization patch :-) This time, I will be breaking it up into digestible chunks! I'll be posting in about one week. Regards Paul On Sun, 4 Dec 2022 at 19:40, Harald Anlauf wrote: > Hi Paul, > > thanks - and it is go

Re: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR [PR107870]

Hi Harald, That's good to commit. Thanks for the patch. Paul On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran wrote: > Dear all, > > here's a small documentation fix for the intrinsic FLOOR. > Besides that, I adjusted the description of the optional > KIND argument to Fortran intrinsi

Re: [PATCH] Fortran: error recovery handling invalid CLASS variable [PR107899]

Hi Harald, It looks good to me. OK to commit. Thanks Paul On Sat, 3 Dec 2022 at 18:27, Harald Anlauf via Fortran wrote: > Dear all, > > the attached obvious patch fixes a NULL pointer dereference > that occurs with an invalid CLASS argument to DEALLOCATE. > > Regtested on x86_64-pc-linux-gnu

Re: [PATCH] Fortran: intrinsic MERGE shall use all its arguments [PR107874]

Hi Harald, It looks good to me. Thanks to you and Steve for the patch. Paul On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran wrote: > Dear all, > > as reported, the Fortran standard requires all actual argument > expressions to be evaluated (e.g. F2018:15.5.3). > > There were two case

Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

Hi Harald, It looks good to me - OK for mainline. Thanks Paul On Fri, 8 Apr 2022 at 21:45, Harald Anlauf via Fortran wrote: > Dear all, > > Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran: > > Dear all, > > > > the logic for checking the allocate-coshape-spec in an ALLOCATE > > statem

Re: [Patch] Fortran: Fix CLASS handling in SIZEOF intrinsic

Hi Tobias, Thanks for the patch and the particularly comprehensive testcase. OK for mainline as far as I am concerned. Paul On Tue, 8 Mar 2022 at 20:06, Tobias Burnus wrote: > Fix SIZEOF handling. > > I have to admit that I do understand what the current code does, > but do not understand wh

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

Hi Harald and Thomas, Thank you for your contributions to understanding the interpretation by different vendors of the F2018 requirements for finalization. While it does appear to be rather chaotic, the differences are down to a small number of "features" of each compiler. Before describing my in

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

for all the help. I have (re)learned to read the standard very > carefully. > > Best regards > > Paul > > > On Fri, 11 Feb 2022, 21:08 Harald Anlauf, wrote: > >> Hi Paul, >> >> Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran: >> >

  1   2   >