[Patch, fortran] PR84074 Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

Hi All, This patch makes sure that offsets and bounds are correct in passing derived types to class formal arrays. It is straightforward enough as not to require explanation. Bootstraps and regtests on FC25/x86_64 - OK for trunk? Paul 2018-02-11 Paul Thomas PR

Re: [Patch, fortran] PR 56691 - [OOP] Allocatable array: wrong offset when passing to CLASS dummy

PR fortran/56691 * gfortran.dg/type_to_class_4.f03: New test. On 27 January 2018 at 12:41, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > I am worried that this fix seems to easy by half and so I am posting > it for approval, rather than committing it as obvio

Re: [Patch, Fortran] PR 84273: Reject allocatable passed-object dummy argument (proc_ptr_47.f90)

Hi Janus, As Steve said, welcome back! I hope that you will post the news of this fix and the correction of the testcases on clf. Talking of which, have you posted the problems that others have found as PRs? It was one of my long deferred tasks to make a start on validating the testsuite and to

Re: [PATCH] PR fortran/82049 -- resolve a charlen if possible

Hi Steve, That's OK for trunk and, if you are possessed of the intestinal fortitude, 6- and 7-branches. Thanks Paul On 7 February 2018 at 02:17, Steve Kargl wrote: > The attached patch fixes PR fortran/82049. Prior to this > patch, gfortran was fouling up

[Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256

Committed a partial patch as 'obvious' in revision 257363. Oddly, the failing test in associate_35.f90 is the only one that works in 7-branch. I have left the PR open and changed the title accordingly. Paul 2018-02-04 Paul Thomas PR fortran/84115 * trans-decl.c

Re: [RFA PATCH] Bug 84094 - several correctness issues in gfortran.dg

Hi Dominique, The patch is OK. By all means open the PR for the missing/confusing diagnostics. Thanks Paul On 4 February 2018 at 13:01, Dominique d'Humières wrote: > Is the following patch OK? For associate_23.f90 I have restricted should_work > to two elements, an

[Patch, fortran] [8.0 Regressions] PR84141 and PR84155

2018-02-03 Paul Thomas PR fortran/84141 PR fortran/84155 * trans-array.c (gfc_array_init_size): Instead of gfc_get_dtype use gfc_get_dtype_rank_type. 2018-02-03 Paul Thomas PR fortran/84141 PR fortran/84155 *

Re: [PATCH, testsuite]: Remove statements with to effect from two fortran testcases

Hi Uros, This is an easy one to OK :-) Backport it as far back as your patience allows. Thanks Paul On 2 February 2018 at 10:32, Uros Bizjak wrote: > Hello! > > Attached patch removes two statements with no effect. These two > statements operate with uninitalized

[Patch, fortran] PR84088 - [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails

This fixes the reduced testcase provided by Tom de Vries in comment #7 of the PR. Committed as 'obvious' as r257262. Will await a report from Tom as to whether or not this fixes the original problem Paul 2018-01-31 Paul Thomas PR fortran/84088 * trans-expr.c

[Patch, fortran] PR 56691 - [OOP] Allocatable array: wrong offset when passing to CLASS dummy

I am worried that this fix seems to easy by half and so I am posting it for approval, rather than committing it as obvious. I would be obliged if somebody would test it thoroughly. Bootstraps and regtests on FC23/x86_64 - OK for trunk and 7 branch? Paul 2018-27-01 Paul Thomas

Re: [Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

Hi Jakub, Thanks for the OK and the help in getting the padding sorted out. Committed as Committed revision 257065. Paul On 24 January 2018 at 20:26, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi Jakub, > > I have made the changes to the types of the dtype el

Re: [PATCH, fortran] Support Fortran 2018 teams

Hi All, Given the delay relative to the start of stage 3, I thought that I had better deal with this asap: + /* TODO: this works on any derived type when + it should only work with team_type. */ + if (team->ts.type != BT_DERIVED) Why don't you give the team_type derived type

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

Hi Jakub, The lateness is indeed embarrassing but couldn't be helped. > Given above my preference would be to keep version an int, and > change rank and type to signed char and attribute to signed short. > That way there will be no padding on either 32-bit or 64-bit targets, > and the structure

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

Janne, Thanks. Jakub, is this OK with you? Paul On 23 January 2018 at 19:09, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > On Mon, Jan 22, 2018 at 9:12 PM, Paul Richard Thomas > <paul.richard.tho...@gmail.com> wrote: >> This patch has been triggered by Thomas's re

[Patch, fortran] PR83866 - [8 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3087

Committed as 'obvious' in revision 256995. Closing PR. Paul 2018-23-01 Paul Thomas PR fortran/83866 * decl.c (gfc_match_derived_decl): If eos not matched, recover and emit error about garbage after declaration. 2018-23-01 Paul Thomas

[Patch, fortran] PR83898 - [6/7/8 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181

Commit as 'obvious' in revision 256994. I will attend to 6- and 7-branches in a little while. Paul 2018-23-01 Paul Thomas PR fortran/83898 * trans-stmt.c (trans_associate_var): Do not set cst_array_ctor for characters. 2018-23-01 Paul Thomas

Re: [Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

Could somebody please review the patch? Thanks Paul On 23 January 2018 at 06:13, Dominique d'Humières wrote: > Dear Paul, > > The test suite passed without new regression with both -m32 and -m64. > > Thanks for the work, > > Dominique -- "If you can't explain

[Patch, fortran] PR37577 - [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

This patch has been triggered by Thomas's recent message to the list. Not only did I start work late relative to stage 3 but debugging took somewhat longer than anticipated. Therefore, to get this committed asap, we will have to beg the indulgence of the release managers and prompt review and/or

Re: [Patch, fortran] PR52162 - Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

Ping! On 8 January 2018 at 14:36, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > I post this patch early last year and did not submit because I was up > to my eyeballs with PR34640. I just forgot about it until it came up > on clf a few days ago. > > Bootstraps

[Patch, fortran] PR52162 - Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

I post this patch early last year and did not submit because I was up to my eyeballs with PR34640. I just forgot about it until it came up on clf a few days ago. Bootstraps and regtests on FC23/x86_64 - OK for trunk? Paul 2018-01-08 Paul Thomas PR fortran/52162 *

[Patch, fortran] PDT bugs PR2 83611 and 83731

This patch adds: (i) Default initializers for parameterized arrays; (ii) Fixes ordinary assignment of PDTs by implementing the same deep copy mechanism as for derived types with allocatable components; and (iii) Fixes the len parameter checking, which failed where the dummy type had an assumed

Re: [patch, libfortran] Use macros for dtype in array intrinsics

Hi Thomas, That was well spotted by Steve! OK for trunk. Thanks Paul On 7 January 2018 at 12:23, Thomas Koenig wrote: > Am 06.01.2018 um 18:45 schrieb Thomas Koenig: >> >> Hello world, >> >> the attached patch removes explicit use of dtype in the >> array intrinsics,

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

n > > On January 1, 2018 at 9:44:59 AM, Paul Richard Thomas > (paul.richard.tho...@gmail.com) wrote: > > Committed to trunk as revision 256065. > > Damian, it would be good if you would confirm that there are no issues > with applying the patch to 7-branch. > > Than

Re: [patch, fortran] Implement simplification of minloc and maxloc

Hi Thomas, Dominique has tested this patch and so, except for a few typos that I communicated to you on #gfortran, this is good for trunk. Somewhere, I have a list of situations where finalization is required but not yet implemented. I'll dig it out and post it on the list. Thanks Paul On 31

Re: [patch, fortran] Complete implementation and correction of simplification

Hi Thomas, This looks very good. OK for trunk. Thanks Paul On 2 January 2018 at 15:53, Thomas Koenig wrote: > Hello world, > > the attached patch implements simplification for cshift completely. > It also fixes a bug where compile-time simplification was handled >

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Committed to trunk as revision 256065. Damian, it would be good if you would confirm that there are no issues with applying the patch to 7-branch. Thanks for all the help. Paul On 28 December 2017 at 19:58, Damian Rouson wrote: > I applied the patch the trunk and

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi All, OK - I'll hold back until I hear from Damian & Zaak. Cheers Paul On 27 December 2017 at 21:06, Damian Rouson wrote: > > Thanks for the additional information Thomas. It sounds like I should test > Paul’s patch. I should be able to do so today and will

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi Thomas, That's a good question. I have kept Damian in copy. It must be said that the OpenCoarray folk are more concerned with PR83319, where there is no problem of binary compatibility. I am awaiting some input from him. Cheers Paul On 27 December 2017 at 17:50, Thomas Koenig

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi Thomas, It will break binary compatibility for caf with scalar, allocatable/pointer components. This comes about because I decided that the caf tokens for thes components, should come after all other components, rather than immediately after the "owner" component. This has the advantage, that

[Patch, fortran] PR83567 - Parametrized derived types: Segmentation fault when assigning a function return value

Hi All, This patch is very straightforward. The PR itself was fixed by not freeing the parameterized components on leaving function scope. The lhs expression in the assignment had pointers to parameterized components that were overwritten on assignment, thereby causing some memory leakage. This

Re: [patch, fortran] Fix PR 83540

OK - thanks for the patch. Paul On 26 December 2017 at 12:12, Thomas Koenig wrote: > Hello world, > > this rather self-explanatory patch makes sure we don't get an error > using reallocation on assignment for inlining matmul when > we don't have reallocation on

Re: [Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

Hi All, This is a complete rework of the patch and of the original mechanism for adding caf token fields and finding them. In this patch, the token fields are added to the derived types after all the components have been resolved. This is done so that all the tokens appear at the very end of the

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Yes - thanks Paul On 10 December 2017 at 17:48, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sun, Dec 10, 2017 at 05:18:53PM +0000, Paul Richard Thomas wrote: >> Hi Steve, >> >> I see that the implementation of the standard is slightly more >>

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Hi Steve, I see that the implementation of the standard is slightly more complicated than I thought. type :: t(a,b) integer, kind :: a integer, len :: b integer(a) :: v(b) end type t type(t(4,:)), allocatable :: z1 type(t(4,10)), allocatable :: z2 allocate (t(4, :) :: z1)

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sat, Dec 09, 2017 at 09:09:14AM +0000, Paul Richard Thomas wrote: >> >> This is good for trunk with one proviso: >> >> This should mutate from: >> - /* TODO understand why this error does not appear

Re: [PATCH] PR fortran/82934,83318 -- Enforce F2008:C631

Hi Steve, This is good for trunk with one proviso: This should mutate from: - /* TODO understand why this error does not appear but, instead, - the derived type is caught as a variable in primary.c. */ - if (gfc_spec_list_type (type_param_spec_list, NULL) != SPEC_EXPLICIT) { -

Re: [Patch, fortran] PRs 82605, 82606 and 82622 - PDT problems

t_10.f03 : Correct for error in coding the for kind 4 component and change the kind check appropriately. * gfortran.dg/pdt_25.f03 : New test. On 30 November 2017 at 12:47, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > This patch fixes the above PRs and the additional p

[Patch, fortran] PRs 82605, 82606 and 82622 - PDT problems

This patch fixes the above PRs and the additional problems in comment #1 of both 82606 and 82622. For the main part, the patch consists of 'obvious' tweaks to the PDT machinery. The exception to this is the chunk in trans-array.c(set_loop_bounds), which is needed to handle parameterized array

Re: (patch, fortran] PR83021 - [7/8 Regression] gfortran segfault in polymorphic assignment

Committed to 7-branch and trunk and r255205 and r255202 respectively. Paul On 26 November 2017 at 18:40, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > This regression was caused by the patch for PR81447. The chunk that > has been modified came

[Patch, fortran] PR83076 - [8 Regression] ICE in gfc_deallocate_scalar_with_status, at fortran/trans.c:1598

This problem is not really a regression but is a "feature" that was exposed by my patch for PR81447. The testcase fails because the caf token for the pointer component is not present in the type. This is fixed in trans-types.c (gfc_get_derived_type) in the manner described in the ChangeLog.

(patch, fortran] PR83021 - [7/8 Regression] gfortran segfault in polymorphic assignment

Dear All, This regression was caused by the patch for PR81447. The chunk that has been modified came about because use association of derived types in block data, in the presence of a vtable, was trying to add vtable procedures, which is not allowed. The original patch did not explicitly target

Re: [Patch, fortran] PR78990 [5/6/7 Regression] ICE when assigning polymorphic array function result

Dear Dominique, Committed to trunk as revision 254936. Thanks for picking up the problem and for redoing the testing. Regards Paul

[Patch, fortran] PR79072 - ICE with class(*) pointer function result and character value

Dear All, This is not quite an 'obvious' patch but it does speak for itself. If there are no objections in the meantime, I will commit it tomorrow evening. Bootstraps and regtests on FC23/x86_64 - OK for trunk? What about 7-branch? Cheers Paul 2017-11-18 Paul Thomas

Re: [Patch, fortran] PR78990 [5/6/7 Regression] ICE when assigning polymorphic array function result

Dear Dominique, Please find attached a revised patch that I believe fixes the problem that you found. The changes are the additions in trans-decl.c. OK for trunk and 7-branch? Paul 2017-11-18 Paul Thomas PR fortran/78990 * expr.c (gfc_is_class_array_function):

Re: [patch, fortran] Fix PR 83012, rejects-valid regression with contiguous pointer

Hi Thomas, This is OK. Thanks Paul On 17 November 2017 at 17:38, Thomas Koenig wrote: > Hello world, > > the attached patch fixes the PR by looking at the function interface if > one exists. > > Regression-tested. OK for trunk? > > Regards > > Thomas > >

Re: [Patch, fortran] PR78990 [5/6/7 Regression] ICE when assigning polymorphic array function result

Hi Dominique, Quite suddenly, I am seeing fault too. I don't know what has changed. I'm on to it. Thanks Paul On 15 November 2017 at 11:40, Dominique d'Humières wrote: > Hi Paul, > > Your patch fixes the ICE and pass the tests. However I see > > At line 22 of file

[Patch, fortran] PR78990 [5/6/7 Regression] ICE when assigning polymorphic array function result

This turned out to be quite a challenging debugging job as often seems to be the case where the scalarizer is involved. Ultimately, I found that the testcase compiled when return_t1 was made a pointer and the resulting code revealed where the problems lay. This modified testcase now works as well

[Patch, fortran] PR82934 - [6/7/8 Regression] Segfault on assumed character length in allocate

Committed as obvious in r254624. I will apply to 6- and 7-branches over the weekend. Although not a regression, the fix prevents an ICE in a particularly robust way. Cheers Paul 2017-11-10 Paul Thomas PR fortran/82934 * trans-stmt.c (gfc_trans_allocate): Remove

[Patch, fortran] PR78619 - [6/7/8 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:889

This regression arose from the patch for PR66465, in which the type check for the associated intrinsic was failing when testing the association of a procedure pointer component with a procedure pointer. See the comment in the patch for an explanation as to why this is an issue. The fix is to

[Patch, fortran] PR69739 - [6/7/8 Regression] ICE during array result, allocatable assignment

Dear All, This is a heads up that, in a few hours, I will apply a patch for PR69739 as 'obvious' unless there are any objections in the mean time. This regression dates back to the time, nearly seven years ago, when I did some work on gfc_map_intrinsic_function. I couldn't figure out how to deal

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

Committed to 7-branch as revision 254429. Paul On 5 November 2017 at 12:44, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi Andre and Thomas, > > Thanks for looking at this. > > I left the condition as it is because it is the same practice as all &

Re: [Patch, fortran] PR78641 - [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor

Hi Steve, Committed to trunk as revision 254428. I will follow with 6- and 7-branches later in the week. Thanks Paul On 4 November 2017 at 14:46, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Sat, Nov 04, 2017 at 12:02:58PM +0000, Paul Richard Thomas wrote: &g

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

Hi Andre and Thomas, Thanks for looking at this. I left the condition as it is because it is the same practice as all sorts of other parts of gfortran. That said, Thomas's suggestion is I think the right one. Committed revision as revision 254427. 7-branch will come later. Regards Paul On 4

Re: [Ping, Fortran, Patch, v1] Three small patches for character arrays

Hi Andre, These patches look fine to me. Thanks for taking account of the array descriptor change between trunk and 7-branch :-) OK for trunk and 7-branch. Thanks Paul On 4 November 2017 at 10:27, Andre Vehreschild wrote: > Ping! > > On Wed, 1 Nov 2017 12:27:11 +0100 > Andre

[Patch, fortran] PR78641 - [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor

Dear All, This patch allows the assignment of class array constructors to derived type arrays. It is straightforward enough that the ChangeLogs and the comment are sufficient explanation. Bootstraps and regtests on FC23/x86_64 - OK for all three branches? Paul 2017-11-04 Paul Thomas

Re: [Patch, fortran] PR81735 - [6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

Corrected in trunk in revision 254404. Cheers Paul On 3 November 2017 at 19:22, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > This was already fixed by the patch for PR82375 on trunk, albeit less > well than the patch applied here. I will correct trunk tomorrow. &

[Patch, fortran] PR81735 - [6/7/8 Regression] double free or corruption (fasttop) error (SIGABRT) with character(:) and custom return type with allocatable

This was already fixed by the patch for PR82375 on trunk, albeit less well than the patch applied here. I will correct trunk tomorrow. Committed as 'obvious' on 6-branch(r254393) and 7-branch(r254389) after bootstrapping and regtesting. Cheers Paul 2017-11-03 Paul Thomas

Re: [Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

Dear All, Please find attached the revised version of the patch following my late realizations in yesterday's submission. Cheers Paul On 1 November 2017 at 18:22, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > This patch is adequately described

Re: [PATCH] PR fortran/82796 -- common entity in equivalence in pure routine

Hi Steve, I read the correspondence on clf and your earlier posting here. With those in mind, the patch looks to be OK to commit. Thanks Paul On 2 November 2017 at 01:09, Steve Kargl wrote: > The attached patch fixes a regression where gfortran was > issuing

[Patch, fortran] PR81447 - [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure

Dear All, This patch is adequately described by the comment in the second chunk applied to resolve.c. Note, however, that the 'unconditionally' is promptly undermined by the subsequent conditions. I will change the adjective appropriately. In writing this, I have just realised that

Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer

Committed to 7-branch as revision 254293. I will close the PR now. Cheers Paul On 30 October 2017 at 22:16, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear Andre, > > Committed to trunk as revision 254244. > > In order to debug the code, I was f

Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer

that I inserted the check for _len > 0 in allocate(). So > it was me causing the bug. Thanks that you found it. The patch looks good to > me. Thanks for the work. > > - Andre > > On Mon, 30 Oct 2017 12:20:20 + > Paul Richard Thomas <paul.richard.tho...@gmail.com> wrot

Re: [PATCH] Fix gfortran.dg/dtio_13.f90 failure on at least FreeBSD

Hi Steve, It looks good to me - OK. Thanks Paul On 30 October 2017 at 18:05, Steve Kargl wrote: > The attached patch fixes the failure of gfortran.dg/dtio_13.f90 > on at least FreeBSD. This test has been failing for a very long > time. In resolve_transfer,

Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer

; Hi Paul, > > whoopsie, I remember that I inserted the check for _len > 0 in allocate(). So > it was me causing the bug. Thanks that you found it. The patch looks good to > me. Thanks for the work. > > - Andre > > On Mon, 30 Oct 2017 12:20:20 + > Paul Richard Thoma

[Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer

Dear All, This bug took a silly amount of effort to diagnose but once done, the fix was obvious. The bug is triggered in this function from the reporter's source file gfc_graph.F90: function GraphIterAppendVertex(this,vertex) result(ierr) !Appends a new vertex to the graph.

[Patch, fortran] PR81758 - [7/8 Regression] [OOP] Broken vtab

Dear All, Thanks to Dimitry Liakh for both reporting the problem and doing a lot of the diagnostic work. Once the offending line in a very complicated code was located, the fix was trivial. Generating a reduced testcase took rather longer :-) The comment in the testcase tells the story. The fix

Re: [Patch, fortran] PR82586 - [PDT] ICE: write_symbol(): bad module symbol

an.dg/pdt_18.f03 : New test. On 20 October 2017 at 18:17, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > The attached patch is pretty clear with the ChangeLogs and is very > nearly obvious. > > Bootstrapped and regtested on FC23/x86_64 - OK for

[Patch, fortran] PR82586 - [PDT] ICE: write_symbol(): bad module symbol

Dear All, The attached patch is pretty clear with the ChangeLogs and is very nearly obvious. Bootstrapped and regtested on FC23/x86_64 - OK for trunk? Paul 2017-10-20 Paul Thomas PR fortran/82586 * decl.c (gfc_get_pdt_instance): Remove the error message that

Re: [Patch, fortran] PR82550 - program using submodules fails to link

rter.net> wrote: > On 10/17/2017 11:33 AM, Paul Richard Thomas wrote: >> The attached patch has a comment that explains what is going on. >> >> Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch? >> > > Yes, looks OK for both. Thanks. > >

[Patch, fortran] PR82550 - program using submodules fails to link

The attached patch has a comment that explains what is going on. Bootstrapped and regtested on FC23/x86_64 - OK for trunk and 7-branch? Paul 2017-10-17 Paul Thomas PR fortran/82550 * expr.c (gfc_check_pointer_assign): A use associated procedure target in a

Re: [Patch, fortran] PR81048 - [6/7/8 Regression] incorrect derived type initialization

Good you caught the missing LF. Thanks! Paul On 13 October 2017 at 19:29, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Fri, Oct 13, 2017 at 07:06:57PM +0100, Paul Richard Thomas wrote: >> >> This patch undoes a side effect of r225447 that had the eff

[Patch, fortran] PR81048 - [6/7/8 Regression] incorrect derived type initialization

Dear All, This patch undoes a side effect of r225447 that had the effect of eliminating the default intialization of derived type array results. The patch corrects the offending changes to the condition in resolve_symbol. Bootstraps and regtests of FC23/x86_64 - OK for trunk, 7- and 6-branches?

Re: [patch, fortran, committed] Small -fdump-fortran-original fixes, plus documentation update

Hi Thomas, I thought that the suggestion to add the original input lines was not bad. It would be even better if -fdump-tree-original could do that. I often time find myself putting a line under the spotlight in a contained subroutine. Thanks for working on -fdump-parse-tree. Cheers Paul On 8

[Patch, fortran] PR82375 - PDT components in PDT declarations fail to compile

Dear All, I ran into Ian Chivers in last week's BCS meeting, who told me that he had found a PDT bug. My response was to post it on Bugzilla, which he did promptly :-) So promptly, in fact, that I felt honour bound to respond in kind. Please find attached a patch to fix his bug and the

Re: [Patch, fortran] PR77296 - [F03] Compiler Error with allocatable string and associate

Committed as revision 253400. Thanks for the review and the test. Paul On 1 October 2017 at 14:24, Thomas Koenig wrote: > Hi Paul, > >> The attached patch fixes the PR and most of the remaining, if not all, >> problems associated with deferred string length targets in

Re: [Patch, fortran] PR 82312 - [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable

Committed as revision 253362. Thanks for taking a look at it. I will wait a week or so before committing to 7-branch. Paul On 1 October 2017 at 14:43, Thomas Koenig wrote: > Hi Paul, > >> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 7 branch? > > > OK for

[Patch, fortran] PR77296 - [F03] Compiler Error with allocatable string and associate

The attached patch fixes the PR and most of the remaining, if not all, problems associated with deferred string length targets in the associate construct. Bootstraps and regtests on FC23/x86_64 - OK for trunk? Paul 2017-09-29 Paul Thomas PR fortran/77296 *

[Patch, fortran] PR 82312 - [7/8 Regression] Pointer assignment to component of class variable results wrong vptr for the variable

Greetings to all, This patch fixes a bug where the pointer assignment to the derived component of a class entity was resulting in the base entity's vptr being set to the vtable of the target. This resulted in the wrong typebound procedure being called. The patch corrects the logic in resolve

Re: [PATCH] Fix fortran/81509

Hi Steve, I'll take your word for it on the F2008 contraints. Given that the patch is very good - OK for trunk. Thanks Paul On 27 September 2017 at 20:36, Steve Kargl wrote: > The attached patch fixes PR fortran/81509. > > In short, F2008 now allows

Re: [Patch, fortran] Bug fixes, including regressions, for the associate construct

2017 at 19:41, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear Jerry, > > Thanks! Committed as revision 253077. > > Cheers > > Paul > > On 21 September 2017 at 01:52, Jerry DeLisle <jvdeli...@charter.net> wrote: >> On 09/20/2017 09:45 A

Re: [Patch, fortran] Bug fixes, including regressions, for the associate construct

Dear Jerry, Thanks! Committed as revision 253077. Cheers Paul On 21 September 2017 at 01:52, Jerry DeLisle <jvdeli...@charter.net> wrote: > On 09/20/2017 09:45 AM, Paul Richard Thomas wrote: >> In the last update to the Parameterized Derived Types implementation, >> I fi

[Patch, fortran] Bug fixes, including regressions, for the associate construct

In the last update to the Parameterized Derived Types implementation, I fixed PR60483 as a side effect. I then checked all the ASSOCIATE bugs and noted that I was responsible for a number of regressions due to a patch that I applied last year. I determined to fix them and found that I couldn't

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

Hi Janus et al., I had to do this quickly because of time pressure and I thought it to be most efficient while the main patch was fresh in my mind. Committed as revision 252039 with attributions suitably modified. Thanks Paul On 11 September 2017 at 20:50, Janus Weil

Re: [PATCH] Fix fortran vector tests on powerpc and aarch64, PR tree-optimization/80925

Hi Steve, This looks fine from the fortran side - especially since it involves removing checks :-) Thanks Paul On 12 September 2017 at 18:34, Steve Ellcey wrote: > Ping, also adding fort...@gcc.gnu.org which I seem to left out when > sending this to

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

Dear Dominique, That error is perfectly correct. Change the order of the assignment and the declaration for 'b' and you will see that all is well. The matching of type parameter specification list follows the same rules as those of actual arguments, except that deferred and assumed expressions

Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

Dear Janus, My profuse apologies for the mis-identification, thereby not giving you the credit. The testcases will, of course be reattributed. Best regards Paul On 11 September 2017 at 20:50, Janus Weil wrote: > Hi Paul, > >> I have fixed all the PDT bugs that have been

[Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

Dear Thomas, dear All, I have fixed all the PDT bugs that have been reported to me so far in the attached patch. The patch is straightforward and is commented for clarity where necessary. Please note that whitespace changes have been suppressed. For this reason, if you are tempted to try the

Re: [Patch, fortran] Parameterized Derived Types

Dear All, The patch has been committed as revision 251925. I look forward to "feedback" (aka PRs) in the coming weeks. I will return to Parameterized Derived Types at the end of this month to clear up some of the known deficiencies (see the notes attached to the patch submission) and any PRs

Re: [patch, fortran] Bug 81296 - derived type I/o problem

Hi Jerry, That looks good to me - OK for trunk and for backporting. Thanks for the patch. Paul PS Did you have time to think about that rather more difficult bug, involving a mix of DT descriptors and intrinsic descriptors for the declared type? On 21 August 2017 at 03:23, Jerry DeLisle

Re: *ping* [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

Hi Thomas, It looks fine to me. OK for trunk. Thanks Paul PS What about PR34640 ? On 9 August 2017 at 20:44, Thomas Koenig wrote: > Am 02.08.2017 um 15:19 schrieb Thomas Koenig: >> >> the attached patch is a bit smaller than it looks, because most of >> it is due

Re: *ping* [patch, fortran] Fix PR 79312, find invalid typespec for empty array constructors

Hi Thomas, This is 'obvious, I think. Yes, OK for trunk. Thanks Paul On 1 August 2017 at 16:09, Thomas Koenig wrote: > Am 24.07.2017 um 23:27 schrieb Thomas Koenig: >> >> Hello world, >> >> the attached patch fixes the PR; patch and test case are rather >>

Re: [patch, fortran] Generate C prototypes from Fortran code

Hi Thomas, This reminds me of project that I once started to translate fortran into C using a similar option. I gave up in the end because I found it more convenient to use a tree dump and modify the declarations by hand. In respect of your query about suggestions, how about outputting

Ping! [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

whitespace problems on the fly. Best regards Paul On 11 July 2017 at 15:48, Jerry DeLisle <jvdeli...@charter.net> wrote: > On 07/11/2017 07:23 AM, Paul Richard Thomas wrote: >> Well, a bit earlier than anticipated, here is the final version that >> puts right all the wrink

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Hi Jerry and Thomas, As Thomas noted, the span field is added in the middle of the descriptor because the caf token field makes the descriptor variable length. This is reflected in the change in libgfortran.h. It has crossed my mind in the last twenty four hours that I should add some more

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Dear All, We are not quite there yet. Thanks to the posters to the thread on clf, I have now been convinced that ptr => der_type_array%comp must return an lbound=1 based descriptor, since the target is not a WHOLE ARRAY as defined in the standard. In addition, Dominique picked up a failing

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Hi Thomas, Hi All, Please find attached what I believe is the final version of the patch. The problem concerning temporaries being generated in lieu of the descriptor being passed directly - see pointer_array_7.f90 and the change to subref_array_4.f90. This latter necessitated a thread on clf to

Re: *Ping* [patch, libgfortran] Use memcpy in a few more places for eoshift

Hi Thomas, The patch is OK by me. Thanks for working on speeding up these library functions. Does the octave version, mentioned in the clf thread, translate easily into C? I had to remind myself of how octave cell arrays function. It is certainly a remarkably concise solution. Cheers Paul On

Re: [patch, fortran] Implement blocked eoshift for eoshift0

Hi Thomas, The timings are impressive! OK for trunk. Thanks Paul On 1 July 2017 at 14:48, Thomas Koenig wrote: > Hello world, > > the attached patch implements the blocked algorithm for > constant shift for dim > 1 for eoshift0 (which handles > the case of constant

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

Paul Thomas <pa...@gcc.gnu.org> PR fortran/34640 * libgfortran/libgfortran.h: Add span field to descriptor. On 24 June 2017 at 11:48, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > Please find attached a draft patch for the above PR, together w

Re: [Patch, fortran] PR34640 - ICE when assigning item of a derived-component to a pointer

at 11:48, Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Dear All, > > Please find attached a draft patch for the above PR, together with PRs > 40737, 55763, 57019 and 57116. These PRs constitute problems > associated with the last F95 feature that gfortran does not c

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