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

Andre Vehreschild vehre@gmx.de
Mon Oct 30 13:48:00 GMT 2017


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 



More information about the Gcc-patches mailing list