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

e invalid because of: > > C1105 (R1105) expr shall not be a designator of a procedure pointer > or a function reference that returns a procedure pointer. > > However: > > On 02.02.21 16:05, Paul Richard Thomas via Fortran wrote: > > > In foo.f90, if I

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

2021 at 14:56, Tobias Burnus wrote: > Hi Paul, > > On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote: > > Regtests on FC33/x86_64 > > OK for master (and maybe for 10-branch?) > > The patch by itself looks good to me, but > > gfortran-trunk assumed_rank_20.f9

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

it without breaking something else. That said, this version of the problem might be easier than most. I will take a look. Cheers Paul On Fri, 29 Jan 2021 at 14:56, Tobias Burnus wrote: > Hi Paul, > > On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote: > > Regtests on FC3

[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

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

[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

but the error is different... if you see what I mean :-) Paul On Wed, 5 Aug 2020 at 16:40, Steve Kargl wrote: > On Wed, Aug 05, 2020 at 03:59:38PM +0100, Paul Richard Thomas wrote: > > The attached patch builds on a draft posted by Steve Kargl. I have left > the > > gcc_as

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)

Subject:Re: [Fortran, OpenACC] Reject vars of different scope in $acc > declare (PR94120) > Date: Tue, 10 Mar 2020 18:02:41 + > From: Paul Richard Thomas > To: Tobias Burnus > > > > Hi Tobias, > > This looks to be straightforward enough to me :-) OK fo

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

This is yet another case, where a deferred character length variable loses the character length backend_decl. As previously, converting the expression and using the string_length recovers it successfully. Regtested on FC31/x86_64 - OK for trunk, followed by 8- and 9-branches after a week or two?

Re: [Patch, fortran] PR93581 - [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

***ping*** On Sun, 1 Mar 2020 at 16:00, Paul Richard Thomas wrote: > > This is a straightforward patch, especially for the bug in the PR! The > additional fix ensures that expr%LEN always returns a scalar. Please > note the comment in resolve.c about bounds checking. > > Regt

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

Andrew, I agree with Steve. That said, I took a look at your patch and it's just fine. OK to commit. Cheers Paul On Mon, 2 Mar 2020 at 02:10, Steve Kargl wrote: > > On Sun, Mar 01, 2020 at 11:43:23PM +0100, Thomas Koenig wrote: > > Am 01.03.20 um 23:42 schrieb Steve Kargl: > > > PS: in

Re: [Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

Committed to head as r10-6952-g7067f8c814088c1d02e40adf79a80f5ec53dbdde Thanks, Thomas Paul On Sun, 1 Mar 2020 at 13:44, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on FC31/x86_64 - OK for trunk? > > > OK. Thanks for the patch! > > Regards > > Thomas -- "If you can't explain

Re: [Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

Committed to head as r10-6954-g957a1b14e99596610abb0777ca86a1c80dde24e0. Thanks, Thomas Paul On Sun, 1 Mar 2020 at 13:43, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ? > > OK, and thanks for the patch. > > I think it makes sense to get

[Patch, fortran] PR93581 - [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

This is a straightforward patch, especially for the bug in the PR! The additional fix ensures that expr%LEN always returns a scalar. Please note the comment in resolve.c about bounds checking. Regtests on trunk - OK for 9- and 10-branches? Paul 2020-03-01 Paul Thomas PR fortran/93581

[Patch, fortran] PR92976 - [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

I am a tiny bit skeptical that this is a regression but I will check. However, it has clearly been there from the early days of OOP without being picked up. The fix is to ensure that the temporary has the correct type of array spec. Regtested on x86_64/FC31 - OK for trunk and 8-/9- branches ?

[Patch, fortran] PR92959 - ICE in gfc_conv_associated, at fortran/trans-intrinsic.c:8634

This is a another case of the gotcha's that come from trying to use ts.u.cl->backend_decl directly, where deferred length and even, in this case fixed length characters are concerned. The fix is to make use of the string length obtained from evaluation of the expression. Regtested on FC31/x86_64

Re: [Patch, fortran] PR92785 - expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

Committed as revision r10-6924-g7485ace81de9ec9dd5c87edf67e359d31ce35a20 On Fri, 28 Feb 2020 at 12:15, Paul Richard Thomas wrote: > > I will commit this tonight as 'obvious' unless there are any > complaints. This descriptor renormalisation is already present in > gfc_conv_deri

[Patch, fortran] PR92785 - expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

I will commit this tonight as 'obvious' unless there are any complaints. This descriptor renormalisation is already present in gfc_conv_derived_to_class. Paul 2020-02-28 Paul Thomas PR fortran/92785 * trans-expr.c (gfc_conv_intrinsic_to_class): Renormalise non- variable

Re: [Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

Committed as r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299 Thanks Paul On Sun, 23 Feb 2020 at 14:25, Thomas Koenig wrote: > > Hi Paul, > > > Regtested on FC31/x86_64 - OK for head? > > Looks good. > > Best of luck committing! > > Regards > > Thomas -- "If you can't explain it

[Patch, fortran] PR57710 - [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

This patch is relatively trivial and represents my first foray into gitland. Thus far, it has been... well, "interesting" compared with svn. Class components of derived types are initialized by calls to trans-array.c(gfc_trans_deferred_array) from trans-decl.c(gfc_trans_deferred_vars). The

Re: *ping**2 Re: [Patch][Fortran] Fix to strict associate check (PR93427)

Hi Tobias, Yes, OK for trunk. I would have been perfectly happy for you to commit as 'obvious'. Cheers Paul On Mon, 3 Feb 2020 at 08:44, Tobias Burnus wrote: > > Another slightly early ping. > > Tobias > > On 1/31/20 3:24 PM, Tobias Burnus wrote: > > *ping* after 4 days. > > > > On 1/27/20

Re: [PATCH] fortran: Fix up ISO_Fortran_binding_15.f90 failures [PR92123]

Hi All, Thank you for taking care of that, Jakub. I have been overwhelmed by daytime work since my last posting and, in addition, have yet to set up a git workflow. This situation is likely to continue for at least another 3-4 months. I will release all the PRs assigned to me, except those

[Patch, fortran] PR92753 - [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392

This patch is straight forward and well explained by the ChangeLogs. The ICE comes about because the simplification of the inquiry_part_ref expressions produced bad expressions. Thanks to Steve for spotting the error in the INQUIRY_RE and INQUIRY_IM parts that was so blindingly obvious that I

Re: [patch, fortran] Fix PR 91783

Hi Thomas, This is OK for trunk. Thanks for the patch Paul On Sun, 24 Nov 2019 at 17:10, Thomas Koenig wrote: > > Hello world, > > this patch fixes a 10 regression in dependency checking. The > approach is simple - if gfc_dep_resolver is handed references > with _data, remove that. > >

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

nd the result is: 5 ptr is no longer associated with assoc Cheers Paul On Mon, 18 Nov 2019 at 10:24, Tobias Burnus wrote: > > On 11/17/19 7:34 PM, Paul Richard Thomas wrote: > […] > Sorry for not yet reviewing the code, but the following caught my eye: > > (gfc_a

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

This is a somewhat delayed patch to fix issues with the original patch, as flagged up by Rainer in comment #12, Rainer in comment #14 and Eric in comment #15. The fix for these problems was posted in April in comment #17. It was thoroughly tested but remained uncommitted because my attention was

[Patch, fortran] PR69654 - ICE in gfc_trans_structure_assign

As I remarked in PR, this fix probably comes 1,379 days too late. I am not at all sure that I understand why I couldn't see the problem because it is rather trivial. I am open to not adding the second gcc_assert - it does seem like overkill. Regtested on FC30/x86_64 - OK for trunk and ?

Re: [Patch] PR fortran/92470 Fixes for CFI_address

I too had some considerable difficulty on this point. I wasn't at all sure that the C world view was relevant here since the API includes CFI_address and, in principle, one could reference directly the elements pointed to by base_addr. However, I bow to the wisdom of your correspondents on the j3

Re: [Patch] PR fortran/92470 Fixes for CFI_address

Hi Tobias, Thanks for taking care of this so rapidly :-) OK for trunk and for 9-branch. Cheers Paul On Tue, 12 Nov 2019 at 14:42, Tobias Burnus wrote: > > Regarding the uncontroversial part: CFI_address. This has been reported > by Vipul Parekh a few hours ago and the problem is: The lower

[patch, fortran] PR92123 - [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedu

The attached patch is verging on the obvious. Thanks to Tobias for spotting Vipul's messages on the J3 list. Regtests on FC30/x86_64 - OK for trunk and 9-branch? Paul 2019-11-03 Paul Thomas PR fortran/92123 *decl.c (gfc_verify_c_interop_param): Remove error asserting that

Re: [Patch,Fortran] PR92284 – gfc_desc_to_cfi_desc fixes

Hi Tobias, OK for trunk and for 9-branch. As with the patch for PR92277, you will have to get release manager approval for 9.2. Thanks for working on this. Cheers Paul On Wed, 30 Oct 2019 at 23:29, Tobias Burnus wrote: > > Playing with the PR92284 test case revealed two issues related to >

Re: [Patch, Fortran] PR92277 - Fix assumed-rank array with bind(C)

Hi Tobias, OK for trunk and for 9-branch. For the latter, you will have to get release manager approval of course. Thanks for picking up my doo-doos. Cheers Paul On Wed, 30 Oct 2019 at 15:40, Tobias Burnus wrote: > > The attached test case (w/o optional and with "this") gave an ICE as >

Re: [Patch, Fortran] PR91863 - fix call to bind(C) with array descriptor

Hi Tobias, Thanks for taking care of this. OK for trunk and 9-branch. Cheers Paul On Wed, 23 Oct 2019 at 14:07, Tobias Burnus wrote: > > With the trunk, there are three issues: > > (a) With bind(C), the callee side handles deallocation with intent(out). > > This should produce the code: >

Re: [Patch, fortran] PR86248 - [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

Hi Steve, Thanks for the heads up. I'll get on to it right away. Regards Paul On Sat, 26 Oct 2019 at 20:04, Steve Kargl wrote: > > On Sat, Oct 26, 2019 at 07:39:55PM +0100, Paul Richard Thomas wrote: > > As far as I can tell, this is a 6-regression as well - ***sigh*** >

[Patch, fortran] PR86248 - [7/8/9/10 Regression] LEN_TRIM in specification expression causes link failure

As far as I can tell, this is a 6-regression as well - ***sigh*** The patch is fundamentally very simple. Symbols that were marked with the fn_result_spec flag that really were module parameters were having the wrong name mangling applied to them. The rest of the patch is a tidy up. Regtested on

[Patch, fortran] PR91926 - assumed rank optional

Please find attached a patch to keep 9-branch up to speed with trunk as far as the ISO_Fortran_binding feature is concerned. It bootstraps and regtests on 9-branch and incorporates the correction for PR92027, which caused problems for trunk on certain platforms. OK to commit? Paul 2019-10-21

Re: [Patch, fortran] PR91926 - assumed rank optional

ixes the fall out. – Thanks! > > On 10/9/19 12:26 PM, Paul Richard Thomas wrote: > > Hi Christophe, > > > > Thanks for flagging this up - I am back at base on Saturday and will > > take it up then. > > > > Regards > > > > Paul > > > > On Wed,

Re: [Patch, fortran] PR fortran/92142 - CFI_setpointer corrupts descriptor

I will deal with this and various other issues associated with ISO_Fortran_binding tomorrow. Thanks for your help Paul On Thu, 17 Oct 2019 at 18:30, Tobias Burnus wrote: > > Hi, > > + fprintf (stderr, "CFI_setpointer: Result is NULL.\n"); > … > > + return CFI_INVALID_DESCRIPTOR; > > +! {

Re: [PATCH] PR fortran/89943 -- Duplicate BIND(c) allowed (?)

3_2.f90: Ditto. > * gfortran.dg/pr89943_3.f90: Ditto. > * gfortran.dg/pr89943_4.f90: Ditto. > > > > On Sat, Oct 12, 2019 at 02:57:25PM +0100, Paul Richard Thomas wrote: > > Hi Steve, > > > > In the F2018 standard: C1550 (R1526) If MODULE appears in

Re: [PATCH] PR fortran/89943 -- Duplicate BIND(c) allowed (?)

Hi Steve, In the F2018 standard: C1550 (R1526) If MODULE appears in the prefix of a module subprogram and a binding label is specified, it shall be the same as the binding label specified in the corresponding module procedure interface body. While it does not say explicitly that a repeat binding

Re: [PATCH] PR fortran/90297 -- Remove code with no functional effect

Hi Steve, As I remarked on the PR thread, it is one of the less harmful bits of code that I introduced :-) OK to commit. Thanks Paul On Sat, 12 Oct 2019 at 01:17, Steve Kargl wrote: > > The patch is fairly self-explanatory. OK to commit? > > 2019-10-11 Steven G. Kargl > > PR

Re: [Patch, fortran] PR91926 - assumed rank optional

Hi Christophe, Thanks for flagging this up - I am back at base on Saturday and will take it up then. Regards Paul On Wed, 9 Oct 2019 at 11:13, Christophe Lyon wrote: > > Hi, > > > On Sat, 5 Oct 2019 at 20:31, Paul Richard Thomas > wrote: >> >> I must apo

[Patch, fortran] PR91926 - assumed rank optional

I must apologise not posting this before committing. I left for a vacation this morning and I thought that this problem and the one posted by Gilles were best fixed before departing. The patch only touches the new ISO_Fortran binding feature and so I thought that I would be safe to do this. It

[Patch, fortran] PR91729 - ICE in gfc_match_select_rank, at fortran/match.c:6586

Fixed as obvious in revision: 276051. The patch is largely due to Steve, for which thanks. Paul 2019-09-23 Paul Thomas PR fortran/91729 * match.c (gfc_match_select_rank): Initialise 'as' to NULL. Check for a symtree in the selector expression before trying to assign a value

[Patch, fortran] PR91726 - [7/8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

Fixing the original problem in the module took a few minutes. Making the module do something useful took rather longer! The testcase in the patch compiles with 6-branch but segfaults in runtime. Bootstrapped and regtested on FC30/x86_64 - OK to commit and go steadily back through the branches

Re: [Patch, Fortran] CO_BROADCAST for derived types with allocatable components

Hi Sandro, This patch looks fine to me. I have a question about the comment: "This code is obviously added because the finalizer is not trusted to free all memory." 'obviously'? Not to me :-( Maybe you can expand on this? As to the stat and errmsg: Leave them for the time being. However, an

<    1   2   3   4   5   6   7   8   9   10   >