Re: [Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated

Hi Tobias, An earlier version of the patch, without the exclusion of unlimited polymorphic expressions caused several regressions. However, omitting the exclusion now causes no regressions. I forgot to go back to this wrinkle. I have included your testcases with appropriate attribution and

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

This patch comes in two versions: submit.diff with Change.Logs or submit2.diff with Change2.Logs. The first fixes the problem by changing array temporaries from class expressions into class temporaries. This permits the use of gfc_get_class_from_expr to obtain the vptr for these temporaries and

[Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated

This patch is straightforward but the isolation of the problem was rather less so. Many thanks to Juergen for testcase reduction. Regtested on FC33/x86_64 - OK for master? Paul Fortran: Fix problem with runtime pointer chack [PR99602]. 2021-03-26 Paul Thomas gcc/fortran/ChangeLog PR

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

Hi Tobias, Please go ahead and commit the patch. I think that your analysis is correct about expr_null and that your patch is the best way to deal with the problem. Best regards Paul On Tue, 23 Mar 2021 at 17:54, Tobias Burnus wrote: > Hi Paul, > > On 23.03.21 18:34, Paul Richard Thomas

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

Cancel the thought on my patchlet null_5.f90 fails on excess errors. Paul On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Tobias, > > I took something of a detour in reviewing this patch. Although short, > understanding it is not straightforward!

Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

Hi Tobias, I took something of a detour in reviewing this patch. Although short, understanding it is not straightforward! Your patch works as advertised and regtests OK (with the patch for PR93660 on board as well). Is NULL the only case where this can happen? Just to aid my understanding, I

Re: [Patch] Fortran: Fix func decl mismatch [PR93660]

Hi Tobias, The patch looks fine to me. OK for 10- and 11-branches. I am not convinced that a delay is needed for the backport. Thanks Paul On Thu, 11 Mar 2021 at 18:19, Tobias Burnus wrote: > This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug. > > Namely TREE_TYPE(fndecl)

Re: [Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated

: > Hi Paul, hi all fortran@/gcc-patch@ reader, > > it looks as if you replied with your patch submission to the wrong email > address – and your re-submission ended up at > https://gcc.gnu.org/PR99602#c17 > > On 16.03.21 18:08, Tobias Burnus wrote: > > On 16.03.21 17:42,

[Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated

Hi Everybody, Although this is 'obvious' I thought that I should post it because I believe that it was triggered by the fix for PR99602 but I just do not have the bandwidth at the moment to test that. The ChangeLog together with the patch is more than sufficient explanation. Regtests OK on

[Patch, fortran] PR99545 [11 Regression] ICE in gfc_trans_assignment since r11-6253-gce8dcc9105cbd404

Applied to all three branches, after regtesting on each, as blindingly obvious. The testcase is the reduced version in comment #6 of the PR. Paul Fortran: Fix problem with allocate initialization [PR99545]. 2021-03-15 Paul Thomas gcc/fortran/ChangeLog PR fortran/99545 * trans-stmt.c

Re: [PATCH] PR fortran/99112 - [11 Regression] ICE with runtime diagnostics for SIZE intrinsic function

Hi Harald, I am not sure of the etiquette for this - it looks OK to me :-) Cheers Paul On Fri, 12 Mar 2021 at 21:20, Harald Anlauf via Fortran wrote: > Dear all, > > the addition of runtime checks for the SIZE intrinsic created a regression > that showed up for certain CLASS arguments to

[Patch, fortran] PR99125 - [9/10/11 Regression] ICE: gimplification failed (gimplify.c:15068)

This problem was caused by the compiler attempting to use 0 as an lvalue and to assign 0 to it. Understandably, this upset the gimplifer quite a bit :-) The fix is to use the ss_info string length for deferred length character components, where the hidden string length component has been used. The

Re: [Patch, fortran] PR99124 - [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541

Hi Tobias, → Can you add also a testcase that which triggers the error message you > see in the unpatched class_assign_4.f90? > > I was unable to find a way to use a typebound operator with a polymorphic > > result > I am confused – the attach testcase does seem to work fine with current >

[Patch, fortran] PR99124 - [9/10/11 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:541

Hi All, This is a straightforward fix that had the side-effect of uncovering an invalid testcase, class_assign_4.f90. I had worked up a new test, based on the one in the PR, and found that another brand determined that it is invalid according to F2018, C15100. I was unable to find a way to use a

Re: [PATCH] PR fortran/99147 - Sanitizer detects heap-use-after-free in gfc_add_flavor

Hi Harald, It looks 'obvious' to me too and is certainly OK for master. Thanks Paul On Thu, 18 Feb 2021 at 21:30, Harald Anlauf via Fortran wrote: > Dear all, > > the PR reports an issue detected with an ASAN instrumented compiler, > which can also be verified with valgrind. It appears

Re: [Patch] Fortran: %re/%im fixes for OpenMP/OpenACC + gfc_is_simplify_contiguous

Hi Tobias, I think that constitutes an 'obvious' patch. OK for mainline. Thanks Paul On Mon, 8 Feb 2021 at 18:53, Tobias Burnus wrote: > Found when looking at Julian's 3/4 OpenACC patch, which has not > yet been committed (and needs still to be revised a bit.) > > The fix (a) avoids an ICE

Re: [Patch] Fortran: Reject DT as fmt in I/O statments [PR99111]

Hi Tobias, The fix and the message are just fine for me. I am trying to imagine how few people will ever encounter this! OK for 10- and 11-branches Thanks Paul On Tue, 16 Feb 2021 at 11:28, Tobias Burnus wrote: > GCC started to accept as legacy extension array-valued > non-characters,

Re: [Patch, fortran] PR98897 - Erroneous procedure attribute for associate name

bug I got before: > When 'double' is parsed, ifort expects that 'precision' follows > ('double precision'). > > > The responses from both compilers to foo3.f90 are the same. > > (I forgot to comment/remove 'procedure(bar) :: var' when > playing around.) Again, this code violate

Re: [Patch] Fortran: Fix rank of assumed-rank array [PR99043]

Hi Tobias, The patch is good for 10- and 11-branches. Thanks Paul On Thu, 11 Feb 2021 at 18:59, Tobias Burnus wrote: > In the Fortran standard, I think it is best explained > in the description of the RANK intrinsic: > > "Example. If X is an assumed-rank dummy argument and > its associated

[Paatch, fortran] PR99060 - [9/10/11 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2411

Thanks to Steve for an 'obvious' patch for this one. It is fixed on all three branches. Paul

Re: [Patch, fortran] PR98897 - Erroneous procedure attribute for associate name

Tue, 2 Feb 2021 at 13:59, Tobias Burnus wrote: > Hi Paul, > > On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote: > > This is more or less 'obvious' and does not require any further > explanation. > > Well, I am not sure whether calling resolve is prematu

[Patch, fortran] PR98897 - Erroneous procedure attribute for associate name

This is more or less 'obvious' and does not require any further explanation. Regtests with FC33/x86_64 - OK for master (and )? Paul Fortran: Fix calls to associate name typebound subroutines [PR98897]. 2021-02-02 Paul Thomas gcc/fortran PR fortran/98897 * match.c (gfc_match_call):

Re: [Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Hi Tobias, I have attached a memory leak free version of the testcase. I have asked for Thomas's help to use frontend-passes.c tools to do the same for compound constructors with allocatable components. My attempts to do the job in other ways have failed totally. Cheers Paul On Fri, 29 Jan

Re: [Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Hi Tobias, Yes, I am aware of the memory leaks. Valgrind, in spite of the dwarf problem, reports definite loss of 3 blocks of 24bytes. This leak from constructors goes back a very long way (PR38319). I have periodically had a stab at fixing it but, thus far, have not successfully eliminated it

[Patch, fortran] PR98342 - Allocatable component in call to assumed-rank routine causes invalid pointer

Fixing the different variants of this PR was somewhat like drawing teeth. Fixing the scalar problem with derived type and class formal arguments was straightforward. However, the need to strip NOPS for scalar unlimited polymorphic arguments was less than obvious. Even less obvious was the problem

[Patch, fortran] PR93924/5 - [OOP] ICE with procedure pointer

This patch fixes PRs 93924/5. It is another 'obvious' patch, whose consequences are very limited. I am trying to slip in as many small ready-to-go patches as I can before we go too far into stage 4. It would be nice to have the patch for PR98573 (posted 23rd Jan) OK'd before the end of the week.

[Patch, fortran] PR98472 - internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352

I have applied another obvious patch to fix this PR. It was tempting to remove both gcc-asserts but I have erred on the side of caution this time. Commit r11-6924-g003f0414291d595d2126e6d2e24b281f38f3448f Again, it is sufficiently safe and obvious that I am tempted to put it on my list of

[Patch, fortran] PR98517 - gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab

Hi All, Fixed as 'blindingly obvious' on 9-, 10- and 11-branches, using Steve's patch. Even if it doesn't fix anything, the patch is totally safe :-) Paul Fortran: Fix deferred character lengths in array constructors [PR98517]. 2021-01-25 Steve Kargl gcc/fortran PR fortran/98517 *

[Patch, fortran] PR98573 - Dynamic type lost on assignment

This is a relatively obvious patch. The chunk in trans-array.c is not part of the fix for the PR but does suppress some of the bad dtype's that arise from allocation of class objects. The part in trans-stmt.c provides vptrs for all class allocations if the expression3 is available. Regtests on

[Patch, fortran] PR98565 - internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950

Fixed as 'obviously correct' as r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da The _data component was preventing the detection of the procedure pointer component and the conversion of the function. Once diagnosed, the fix is obvious. Regtested on FC33/x86_64 - OK in a few weeks for 9- and

Re: [Patch, RFC] PR fortran/93340 - [8/9/10/11 Regression] fix missed substring simplifications

Hi Harald, It looks OK to me. I can see why you are asking about the implementation but cannot offer a better solution. OK for master. Thanks Paul On Tue, 12 Jan 2021 at 22:03, Harald Anlauf via Fortran wrote: > Dear all, > > when playing around with the issues exposed by PR93340,

Re: [PATCH] PR fortran/98661 - valgrind issues with error recovery

Hi Harald, That's OK for master. Thanks Paul On Wed, 13 Jan 2021 at 21:25, Harald Anlauf via Fortran wrote: > Dear all, > > the former Fortran testcase charlen_03.f90, which some time ago used to > ICE, could still display issues during error recovery. As Dominique > pointed out, this

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

Hi All, This patch was triggered by a thread on clf. Some years ago Tobias and I discussed the remaining conditions where finalization should be triggered and is not. Intrinsic assignment was one of the glaring omissions for which implementation looked like a heavy lift job. As it happens, it

Re: [PATCH] PR fortran/96381 - invalid read in gfc_find_derived_vtab

Hi Harald, It looks good to me - OK for master and backporting. Thanks Paul On Fri, 1 Jan 2021 at 16:14, Harald Anlauf via Fortran wrote: > Dear all, > > happy New Year! > > The testcase committed with the fix for PR93337 uncovered a latent issue > with an invalid read that was discovered

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

Hi Thomas, Thanks - applied to master in r11-6365-geeb145317b42d5203056851435457d9189a7303d . I wonder if this one deserves backporting? Cheers Paul On Tue, 29 Dec 2020 at 09:06, Thomas Koenig wrote: > > Hi Paul, > > > Regtests on FC33/x86_64 - OK for master? > > OK. Thanks for the

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

Hi Thomas, Thanks for taking a look at the patch. Applied to master as r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7 . The branches will follow in a week or so. Regards Paul On Mon, 28 Dec 2020 at 17:10, Thomas Koenig wrote: > Hi Paul, > > >> > > Retested on FC33/x86_64 - OK for

[Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

Hi All, Another one bites the dust! The patch is commented such that it is self-explanatory. Regtests on FC33/x86_64 - OK for master? Paul Fortran: Correct missing structure constructor comps. [PR97612]. 2020-12-27 Paul Thomas gcc/fortran PR fortran/97612 * primary.c

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

Hi All, I am in the midst of an end-of-year tidy up and found this: On Wed, 1 Apr 2020 at 18:07, Fritz Reese wrote: > Unfortunately the mailing list stripped off this attachment so we do > not have a chance to review. As attachments appear to be working > lately, please resubmit this patch. >

Re: Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)

Hi Thomas, Thanks for the OK. Pushed as to master as commit r11-6346-gc4a678981572c12d158709ace0d3f23dd04cf217 Cheers Paul On Sat, 26 Dec 2020 at 19:01, Thomas Koenig wrote: > Hi Paul, > > > Ping! > > OK. > > Thanks a lot! > > Best regards > > Thomas > -- "If you can't explain it

Ping: [Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)

Ping! On Sat, 12 Dec 2020 at 10:38, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Fortran: Fix some select rank issues [PR97694 and 97723]. > > Hi All, > > Unlike select type, select rank selectors retain the allocatable > attribute. This is corrected by the chunk in check.c.

[Patch, fortran] PR

Fortran: Enable inquiry references in data statements [PR98022]. This patch speaks for itself. Regtests on FC31/x86_64 - OK for master? Paul 2020-12-12 Paul Thomas gcc/fortran PR fortran/98022 * data.c (gfc_assign_data_value): Handle inquiry references in the data statement object list.

[Patch, fortran] PR97694 - ICE with optional assumed rank class(*) argument (and PR97723)

Fortran: Fix some select rank issues [PR97694 and 97723]. Hi All, Unlike select type, select rank selectors retain the allocatable attribute. This is corrected by the chunk in check.c. Note the trailing whitespace corrections. Resolution of select rank construct must be done in the same way as

Re: [Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Thomas, Yes, it did grow into a bit of a monster patch. I kept noticing rather flakey bits of existing code, especially where matching of dtype element lengths to the actual payload was concerned. Waiting for the others to comment gives me a chance to write a more comprehensive testcase for

[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Everyone, I am afraid that this is a rather long sad story, mainly due to my efforts with gfortran being interrupted by daytime work. I posted the first version of the patch nearly a year ago but this was derailed by Tobias's question at:

Re: [PATCH] fortran/97652 - workaround missing canonicalization of PDT types

Hi Richi, That's OK for master and as far back as you have the fortitude to go. Thanks for the fix. I agree that we should always pick up a canonical variant. When I finally get "a minute or two" to fix the rather fundamental problems with PDTs, I will make sure that this goes away. I am also

Re: [Patch] Fortran: Add !GCC$ attributes DEPRECATED

Hi Tobias, That looks to be the best that can be done with a sensible amount of effort. OK by me. Regards Paul On Mon, 2 Nov 2020 at 19:09, Tobias Burnus wrote: > This adds the Fortran equivalent to __attribute__((deprecated)), > except that "deprecated(message)" is not supported and that

Re: [Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Ping! On Thu, 29 Oct 2020 at 15:59, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Everyone, > > I am afraid that this is a rather long sad story, mainly due to my efforts > with gfortran being interrupted by daytime work. I posted the first version > of the patch nearly a year

[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Everyone, I am afraid that this is a rather long sad story, mainly due to my efforts with gfortran being interrupted by daytime work. I posted the first version of the patch nearly a year ago but this was derailed by Tobias's question at:

Re: [PATCH] Refactor array descriptor field access

Hi Richard, This looks good to me. OK for master. Do you have any plans to backport to 10-branch, say? Thanks Paul On Tue, 27 Oct 2020 at 09:28, Richard Biener via Fortran < fort...@gcc.gnu.org> wrote: > On Fri, Oct 16, 2020 at 10:47 AM Richard Biener wrote: > > > > This refactors the array

Re: [PATCH] PR fortran/97491 - Wrong restriction for VALUE arguments of pure procedures

Hi Harald, OK for master and 10-branch if you want. Thanks Paul On Mon, 26 Oct 2020 at 21:00, Harald Anlauf wrote: > As found/reported by Thomas, the redefinition of dummy arguments with the > VALUE attribute was erroneously rejected for pure procedures. A related > purity check did not

Re: [patch, fortran] Partial fix for PR97454, declarations of some library functions

Hi Thomas, OK for master. Thanks for working on this one! Paul On Fri, 16 Oct 2020 at 20:33, Thomas Koenig via Fortran wrote: > Hello world, > > here's a patch which corrects some wrong declarations (and fixes > the segfault for FINDLOC on Darwin ARM). > > Regression-tested. OK for trunk? >

Re: [PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)

Hi Mark, OK for master. If you want to backport, that's fine by me but please give it a few weeks. Thanks for fixing this. Paul On Tue, 13 Oct 2020 at 08:17, Mark Eggleston wrote: > **ping** > > previously omitted commit message added > > On 29/09/2020 14:03, Mark Eggleston wrote: > > For

Re: [Patch] Fortran: add contiguous check for ptr assignment, fix non-contig check (PR97242)

Hi Tobias, This looks good to me - OK for master. Thanks for the patch Paul On Wed, 30 Sep 2020 at 09:59, Tobias Burnus wrote: > The non-contiguous had both check false positive and false > negative results. Some more refinements > are surely possible, but hopefully there are no longer >

[Patch, fortran] PR/97045 A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument

Hi All, The original testcase turned out to be relatively easy to fix - the chunks in trans-expr.c and trans-stmt.c do this. However, I tested character actual arguments to 'write_array' in the testcase and found that the _len component of the unlimited polymorphic dummy was not being used for

[Patch, fortran] PR96495 - [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

This patch detects a scalar function result that has allocatable components and is being used inside a scalarization loop. Before this patch, the components would be deallocated and nullified within the scalarization loop and so would cause a segfault on the second cycle of the loop. The stored

[Patch, fortran] PR96624 - A segment fault occurred when using the reshape function result to assign a variable

Hi All, Here is another of Steve Kargl's patches. Before the patch is applied, the following code is generated: atmp.0.span = 4; atmp.0.data = 0B; atmp.0.offset = 0; (*(integer(kind=4)[0] * restrict) atmp.0.data)[0] = 1; (*(integer(kind=4)[0] * restrict) atmp.0.data)[1] = 2;

[Patch, fortran] PRs 96100 and 96101 - Problems with string lengths of array constructors

Hi All, The fix for PR9601 is rather trivial and is the last chunk of the patch. Finding the fix for PR96100 took a silly amount of time but it now looks rather obvious. Trying to evaluate the string length by calling gfc_conv_expr_descriptor, when this function is already failing to find it is

[Patch, fortran] PR96312 - [10/11 Regression] Reallocation on assignment uses undefined variables

Hi All, trans-expr.c(fcncall_realloc_result) unconditionally compared the shapes of the function result and the lhs. This is clearly wrong when the lhs is not allocated since the bounds could be used uninitialized as found by the reporter. The patch does the obvious thing by checking the

Re: [Patch, fortran] PR96102 - ICE in check_host_association, at fortran/resolve.c:5994

Dear All, Dominique has kindly pointed out that the error message in the patch does not correspond to the errors in the testcase. This came about because the submitted patch was an earlier version of that on my tree. Please find attached the correct version of the patch. The principle is the same

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

I must say that I was thinking rather more of the INTENT(IN) case to make sure that it is accepted. Paul On Wed, 5 Aug 2020 at 17:41, Thomas Koenig wrote: > Hi Paul, > > > This is OK by me. > > Committed (or should I say "pushed"?), thanks! > > > Is it worth testing the INTENT variants? > > I

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

Hi Thomas, This is OK by me. Is it worth testing the INTENT variants? Cheers Paul On Tue, 4 Aug 2020 at 20:03, Thomas Koenig via Fortran wrote: > Hello world, > > the attached patch issues an error for something that I am sure most > people did at least once (I know I did), something like

[Patch, fortran] PR96102 - ICE in check_host_association, at fortran/resolve.c:5994

The attached patch builds on a draft posted by Steve Kargl. I have left the gcc_assert in place just in case my imagination was too limited to generate an ICE. Regtests OK on FC31/x86_64 - OK for trunk? Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/resolve.c

[Patch, fortran] PR96325 - Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

The attached patch regtests on FC31/x86_64 - OK for trunk? Cheers Paul Commit message: This patch fixes PR96325. See the explanatory comment in the testcase. 2020-08-01 Paul Thomas gcc/fortran PR target/96325 * primary.c (gfc_match_varspec): In the case that a component reference is added

Re: [Patch, fortran] PR96320 - gfortran 8-10 shape mismatch in assumed-length dummy argument character array

Hi Thomas, I discovered the bit about the ChangeLogs last night but thanks for the warning:-) The commit message reads: This patch fixes PR96320. See the explanatory comment in the testcase. 2020-08-01 Paul Thomas gcc/fortran PR target/96320 * interface.c (gfc_check_dummy_characteristics):

[Patch, fortran] PR96320 - gfortran 8-10 shape mismatch in assumed-length dummy argument character array

Hi All, This is my first foray into gfortran for quite a little while so I am going cautiously on this 'obvious' patch. The comment in the patch and the ChangLog are clear enough that no further explanation is needed. Regtests on FC31.x86_64 - OK for trunk? I am a bit reluctant to get into

Re: *ping* [patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

Hi Thomas, I am fine with this being in frontend-passes.c - it was just a question :-) resolve.c has become too large anyway. The testcase looks familiar! Don't forget to commit and push the additional source too. OK for 10-- and all the affected branches. Cheers Paul On Sat, 18 Jul 2020 at

Re: *ping* [patch, fortran] Fix PR 96018, wrong code caused by implicit_pure

Hi Thomas, The patch looks fine to me but I have two questions: (i) Why is this not done in resolve.c? (ii) Is Martin's reduced reproducer not the basis for a testcase? Regards Paul On Sat, 18 Jul 2020 at 11:58, Thomas Koenig via Fortran wrote: > Ping? > > > the attached patch fixes a

Re: *ping* [patch, fortran] PR 27318, warn if interfaces do not match

Hi Thomas and Dominique, The patch looks fine to me. If Dominique has nothing to report then it is OK for trunk. Thanks Paul On Thu, 2 Jul 2020 at 11:15, wrote: > Le 2020-06-30 23:39, Thomas Koenig a écrit : > > OK, > > > > so here is an updated version, which includes the updated test

Re: [PATCH, part2] PR fortran/95373 - [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

Hi Harald, That looks good to me for all three branches. Cheers Paul On Fri, 29 May 2020 at 23:00, Harald Anlauf wrote: > The initial attempt to fix this PR unfortunately produced a regression > in the testsuite that was overlooked. The real fix is to apply this > check in the appropriate

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

Hi Thomas, You didn't attach the testcase but never mind, I am sure that it is OK :-) OK for trunk and, if you feel like it, for 9-branch. Thanks Paul On Tue, 21 Apr 2020 at 22:56, Thomas Koenig via Fortran wrote: > Hello world, > > this one took a bit of detective work. When array

Re: [Patch][Fortran] Fix error cleanup of select rank (PR93522)

Hi Tobias, I would say that if any patch were obvious, that one is :-) OK. Thanks Paul On Mon, 30 Mar 2020 at 09:16, Tobias Burnus wrote: > Early *ping*. > > Tobias > > On 3/27/20 11:06 AM, Tobias Burnus wrote: > > > Hi all, > > > > here, the reject_statement cleanup and the freeing of the

Re: [Patch, Fortran] Reject invalid association target (PR93363)

Hi Tobias, Thanks for the patch. I had flagged it up as one that I should be dealing with. OK indeed! Cheers Paul On Fri, 27 Mar 2020 at 08:05, Tobias Burnus wrote: > > Using "associate (y => procedure_name)" and > "associate (y => derived_type_name)" failed with an ICE > when converting to

[Patch, fortran] PR94246 - [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

This turned out to be relatively trivial, following a fair amount of head scratching:-( Regtests on FC31/x64_86 - OK for both branches? Paul 2020-03-26 Paul Thomas PR fortran/94246 * expr.c (scalarize_intrinsic_call): Remove the error checking. Make a copy of the expression to

Re: Re: [Fortran, OpenACC] Reject vars of different scope in $acc declare (PR94120)

I would swear that I selected "reply all" but... Never mind, you put it right! Cheers Paul On Thu, 12 Mar 2020 at 08:44, Tobias Burnus wrote: > > (I assume that should have gone to gcc-patches@ and fortran@ as well.) > > > Forwarded Message > Subject:Re: [Fortran,

<    1   2