This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Andre Vehreschild <vehre at gmx dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, liakhdi at ornl dot gov
- Date: Mon, 30 Oct 2017 22:16:25 +0000
- Subject: Re: [Patch, fortran] PR80850 - Sourced allocate() fails to allocate a pointer
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiJOnb4Y_300BRb66cRUb9pu4=LML-NuW67EO7LZks6XyA@mail.gmail.com> <20171030143933.176f61e1@vepi2>
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 <vehre@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.thomas@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 <pault@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