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 Fortran wrote:

[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

Thanks Gents! The solution is to gfc_free_expr (p) if the replacement is not made. I am regtesting a patch for PR107900. I'll include the fix for the memory leak in the patch for that. Cheers Paul On Thu, 8 Jun 2023 at 09:30, Harald Anlauf wrote: > > On 6/8/23 09:46, Mikael Morin wrote: > >

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

Thanks Mikael. Pushed as r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d I should have credited you with the comments that you made about the half baked patch, which pushed me to this patch. Regards Paul On Thu, 1 Jun 2023 at 18:58, Mikael Morin wrote: > Le 01/06/2023 à 17:20, Paul

[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

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

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

gfc_add_block_to_block (pblock, ); > +} > >if (cl->backend_decl && VAR_P (cl->backend_decl)) > gfc_add_modify (pblock, cl->backend_decl, se.expr); > > Cheers > > Paul > > > On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote: > >> Hi P

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

>backend_decl, se.expr); Cheers Paul On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote: > Hi Paul, > > On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote: > > duuuh! Please find them attached. > > the patch LGTM. Thanks! > > However, I have comments on the n

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 T

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]

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

Hi All, Please find attached the patch to fix the dg directives and remove a lot of trailing white space. Unless there are any objections, I will commit as obvious over the weekend. Cheers Paul Fortran: Fix dg directives and remove trailing whitespaces in testsuite 2023-04-07 Paul Thomas

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 fi

[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

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

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

Hi Manfred, Indeed I do :-) Thanks for the spot. I have decided that it will be less messy if I roll all the testcases into one or, perhaps two => associate_xx.f90 Forgetting the space before the final brace seems to be rife! Cheers Paul On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote:

[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

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

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

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

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

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

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

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

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

t; thanks - and it is good to see that you are back! > > Harald > > Am 04.12.22 um 12:48 schrieb Paul Richard Thomas via Gcc-patches: > > Hi Harald, > > > > That's good to commit. > > > > Thanks for the patch. > > > > Paul > > > > > > &

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

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

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

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

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

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

Hi Harald, I have run your modified version of finalize_38.f90, and now I see > that you can get a bloody head just from scratching too much... > > crayftn 12.0.2: > > 1, 3, 1 > It appears that Cray interpret a derived type constructor as being a function call and so "6 If a specification

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

Hi Harald, Thanks for giving the patch a whirl. > the parent components as an array. I strongly suspect that, from reading > > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, > this > > is another issue to come back to in the future. > > Could you specify which version of

Re: [PATCH] PR fortran/104311 - [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce

Hi Harald, Indeed, this is obvious, as you say. OK for the affected branches. Regards Paul On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran wrote: > Dear Fortranners, > > a check in gfc_calculate_transfer_sizes had a bug in the logic: > it did not trigger for MOLD having a storage

Re: [PATCH] fortran: Unshare associate var charlen [PR104228]

Hi Harald and Mikael, This looks fine to me. OK for all the listed branches. Thanks for the patch Paul On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran wrote: > Hi Mikael, > > Am 29.01.22 um 15:24 schrieb Mikael Morin: > > Hello, > > > > the attached patch is a fix for PR104228. > >

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

This patch has been an excessively long time in coming. Please accept my apologies for that. All but two of the PR37336 dependencies are fixed, The two exceptions are PRs 59694 and 65347. The former involves lack of finalization of an unreferenced entity declared in a block, which I am sure is

[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS

Hi All, Strictly speaking, the attached patch is branching out into a more generalised attack on PR37336(Finalization) - [F03] Finish derived-type finalization but most of it fixes PR64290. I started work on this patch almost a year ago but had to drop it due daytime work pressure and only

[Patch, fortran] PR103366 - [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

I doubt that this is a regression on 9-11 branches since the testcase compiles correctly on each of my copies of these branches. IMHO it is rather more likely to have been caused by 64f9623765da3306b0ab6a47997dc5d62c2ea261, which introduced this new form of gfc_conv_gfc_desc_to_cfi_desc. The

Re: [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258]

Hi Sandra, That's a good shout to query suppress_errors. The patch is OK by me. Thanks Paul On Wed, 5 Jan 2022 at 03:21, Sandra Loosemore wrote: > This patch fixes an ICE that appeared after I checked in my patch for > PR101337 back in November, which made the resolve phase try harder to >

Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366

Hi Harald, That is the sort of thing that I had in mind. Is it worth adding the check for CLASS_DATA? I cannot remember if that is made redundant by the test of the class_ok attribute. Cheers Paul On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote: > Hi Paul, > > Am 28.12.21 um 12:56 schrieb

Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366

Hi Harald, This looks good to me. OK for mainline and, dare I suggest, 11-branch? >From a quick run through resolve.c, there are many places where the extra checks that you introduced in the patch have been implemented. This makes me wonder whether a function or macro might not make the relevant

Re: [committed] Fortran: Add more documentation for mixed-language programming

Hi Sandra, Looks good to me. Thanks Paul On Fri, 5 Nov 2021 at 21:13, Sandra Loosemore wrote: > I was recently pinged about PR35276. It's an old issue, but a couple of > the concerns raised there haven't been fixed yet, so I've checked in > this patch to fill in the gaps. > > -Sandra >

Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)

Hi Tobias, My disappearance is partly responsible for the backlog. I told José that I would start working on it some months since but just have not had the time. I can do some of the reviews but still do not have much time to spare. Perhaps you could divide them up between us. Andrew Benson has

Re: [Patch] Fortran: Fix CLASS conversion check [PR102745]

Hi Tobias, This is OK for mainline and as far back in the branches as you feel inclined to go. Thanks for the patch. Paul On Fri, 15 Oct 2021 at 22:19, Tobias Burnus wrote: > This patch fixes two issues: > > First, to print 'CLASS(t2)' instead of: > Error: Type mismatch in argument ‘x’ at

Re: [Patch] [v3] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)

Hi Tobias, I can only echo Harald's comment that this is an impressive bit of work. I spent some time messing with fc-descriptor-7.f90/gc-descriptor-7-c.cc because it kept failing on me. This came about because I missed one of the chunks not applying in the C component of the test; namely: for

Re: *PING**2 – Re: [Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check

Hi Tobias, s/However, as argument they are also iteroperable/However, as an argument they are also interoperable/ s/ /* else: valid only sind F2018 - and an assumed-shape/rank array; however, gfc_notify_std is already called when those array type are used. Thus, silently accept F200x. */

Re: [PATCH] PR fortran/87737 - ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923

Hi Harald, It looks good to me. OK for mainline. You might even consider backporting to 11-branch. Best regards Paul On Fri, 27 Aug 2021 at 21:15, Harald Anlauf via Fortran wrote: > Dear all, > > the ICE in the original testcase does no longer occur but leads to an > error in a later stage

Re: PING [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

Hi Harald, Looks good to me - OK for as many branches as you have sufficient fortitude for. Regards Paul On Thu, 3 Jun 2021 at 21:22, Harald Anlauf via Fortran wrote: > *PING* > > > Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr > > Von: "Harald Anlauf" > > An: "fortran" , "gcc-patches" <

Re: [Patch, fortran] PR fortran/100120/100816/100818/100819/100821 problems raised by aggregate data types

Hi José, I can second Dominique's thanks. I applied it to my tree when you first posted, set the regtest in motion and have not been able to return to gfortran matters since. OK for master. I am especially happy that you have tackled this area and have rationalised it to a substantial degree.

Re: [PATCH] PR fortran/100551 - [11/12 Regression] Passing return value to class(*) dummy argument

Hi Harald, I meant to deal with this myself since I am the guilty party. However, the last two weeks have been taken up by a house move and so gfortran has been on the backburner. The patch looks good and seems to do the job - OK for master and 11-branch. Thanks a million for dealing with it!

Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays

It's 46991 of course. Many thanks Paul On Thu, 6 May 2021 at 17:15, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Blast! Thanks for pointing it out. The testcase is in a directory > ~/prs/pr46691, which I then took from the editor. Original sin and all > that. > > Paul > >

Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays

Blast! Thanks for pointing it out. The testcase is in a directory ~/prs/pr46691, which I then took from the editor. Original sin and all that. Paul On Thu, 6 May 2021 at 17:06, Jonathan Wakely wrote: > PR 46691 is the wrong PR number: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 >

Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays

Hi All, Please find below a corrected ChangeLog. Sorry that I didn't get it right first go. Paul Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the

[Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays

Hi All, Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me that I became locked into it :-( After extensive, fruitless rummaging through decl.c and trans-decl.c, I realised that the problem was far simpler than it seemed and that it lay in class.c. After that PR was fixed,

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

Ping! On Tue, 20 Apr 2021 at 12:51, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This is another PDT warm-up patch before tackling the real beast: PR82649. > > As the contributor wrote in the PR, "The F08 standard clearly > distinguishes between type parameter

Re: [Patch, fortran] PR fortran/82376 - Duplicate function call using -fcheck=pointer

Hi José! The fix is fine. Note however that the testcase will pass even without the fix because you haven't included the ! { dg-options "-fcheck=pointer" }. In fact, I suggest that you use the version of the tescase that I have attached that does not run but counts the number of occurrences of

Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference

Hi Harald, Another good one - OK for master but wait a while for 11-branch. I am a bit hesitant about 10-branch because this is not a regression. That said, this is harmless because it is permissive, so I will leave it to you to decide. Is there a test for an error with -std=f2003? If not, you

Re: [Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Hi Harald, It looks good to me! Keep clear of 11-branch until release but OK for the others. Thanks Paul On Fri, 23 Apr 2021 at 00:18, Harald Anlauf via Fortran wrote: > Now with the correct patch attached ... > > Sorry for the confusion! > > --- > > Dear Fortranners, > > we need to check

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

Hi All, This is another PDT warm-up patch before tackling the real beast: PR82649. As the contributor wrote in the PR, "The F08 standard clearly distinguishes between type parameter definition statements and component definition statements. See R425, R431, R435, and in particular see Note 6.7

Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable

; reported by valgrind, given the decrease in the malloc count. > >> > >> Cheers > >> > >> Paul > >> > >> > >> On Mon, 19 Apr 2021 at 14:08, Tobias Burnus >> <mailto:tob...@codesourcery.com>> wrote: > >> > >>

Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable

aul, > > On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote: > > I was just about to announce that I will only do backports and > regressions, > > while I finally attack the fundamental problem with the representation of > > Parameterized Derived Types. Then this PR c

[Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable

Hi All, I was just about to announce that I will only do backports and regressions, while I finally attack the fundamental problem with the representation of Parameterized Derived Types. Then this PR came up that was such clear low hanging fruit that I decided to fix it right away. Regtests on

Re: [PATCH] docs: Remove empty table column.

Hi Martin, It looks good to me - please push before release. Thanks Paul On Mon, 12 Apr 2021 at 16:59, Martin Liška wrote: > A column with empty values seems suspicious. > > Ready to be installed? > Thanks, > Martin > > gcc/fortran/ChangeLog: > > * intrinsic.texi: The table has

Re: [Patch, fortran v2] PR fortran/84006, PR fortran/100027 - ICE on storage_size with polymorphic argument

Hi Jose, Please take a look at my reply on the PR, which points to PR98534. Regards Paul On Fri, 16 Apr 2021 at 20:47, José Rui Faustino de Sousa via Fortran < fort...@gcc.gnu.org> wrote: > Hi All! > > Proposed patch to: > PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS

Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test

preremark I want to note that the testcase class_assign_4.f90 > > was added for PR83118/PR96012 (fixes problems in handling > > class objects, Dec 18, 2020) > > and got revised for PR99124 (class defined operators, Feb 23, > > 2021). > &g

Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test

e class_assign_4.f90 >> was added for PR83118/PR96012 (fixes problems in handling class objects, >> Dec 18, 2020) >> and got revised for PR99124 (class defined operators, Feb 23, 2021). >> Both patches were then also applied to GCC 9 and 10. >> >> On 26.

Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test

96012 (fixes problems in handling class objects, > Dec 18, 2020) > and got revised for PR99124 (class defined operators, Feb 23, 2021). > Both patches were then also applied to GCC 9 and 10. > > On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote: > > This patch c

Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

Hi Jerry, A belated thanks is in order. Pushed as fc27115d6107f219e6f3dc610c99210005fe9dc5. I'll wait a little while for 10-branch since it is an ICE on wrong code. Regards Paul On Fri, 2 Apr 2021 at 04:11, Jerry DeLisle wrote: > Paul, > > This looks OK to me for Trunk. I believe 10 is in

[Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186

This one is trivial. The wrong error message was transformed by my patch for PR98897 into an ICE. This patch now produces the correct error. Regtests OK on FC33/x86_64 - OK for the affected branches? Paul Fortran: Fix ICE on wrong code [PR99818]. 2021-04-01 Paul Thomas

  1   2   >