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 forced to use 7-branch for > development since there were dependencies that detected the change in > module number. 7-branch accepted the assignments without casts but I > was forced to include them in trunk. As advertised the testcase just > enforces the assignment to the _len field through a tree dump. > > 7-branch will come on Wednesday. Tomorrow is full of Halloween fun.... > > Thanks > > Paul > > > On 30 October 2017 at 13:39, Andre Vehreschild <ve...@gmx.de> wrote: >> 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 +0000 >> Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: >> >>> 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. >>> implicit none >>> integer(INTD):: ierr !out: error code >>> class(graph_iter_t), intent(inout):: this !inout: >>> graph iterator >>> class(graph_vertex_t), intent(in), target:: vertex !in: new vertex >>> type(vert_link_refs_t):: vlr >>> >>> ierr=this%vert_it%append(vertex) !<===== right here! >>> ....snip.... >>> return >>> end function GraphIterAppendVertex >>> >>> 'vertex' is being passed to a class(*) dummy. As you will see from the >>> attached patch and the ChangeLog, 'vertex' was being cast as unlimited >>> polymorphic and assigned to the passed actual argument. This left the >>> _len field indeterminate since it is not present in normal (limited?) >>> polymorphic objects. >>> >>> Further down the way, in stsubs.F90(clone_object) an allocation is >>> being made using the unlimited version of 'vertex as a source. Since >>> the size passed to malloc for an unlimited source is, for _len > 0, >>> the value of the _len multiplied by the vtable _size, the amount of >>> memory is also indeterminate and causes the operating system to flag a >>> failed allocation, pretty much at random. >>> >>> The ChangeLog and the patch describe the fix sufficiently well as not >>> to require further explanation. I will write a testcase that tests the >>> tree dump for the _len field before committing the patch. >>> >>> Bootstraps and regtests on FC23/x86_64 - OK for 7- and 8-branches? >>> >>> If I do not receive any contrary comments, I will commit tonight. >>> >>> Regards >>> >>> Paul >>> >>> 2017-10-30 Paul Thomas <pa...@gcc.gnu.org> >>> >>> PR fortran/80850 >>> * trans_expr.c (gfc_conv_procedure_call): When passing a class >>> argument to an unlimited polymorphic dummy, it is wrong to cast >>> the passed expression as unlimited, unless it is unlimited. The >>> correct way is to assign to each of the fields and set the _len >>> field to zero. >> >> >> -- >> Andre Vehreschild * Email: vehre ad gmx dot de > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein