This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.thomas@gmail.com> wrote:
> 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 access=private need not
> have a vtable generated unless it is required for a class within the
> module. I will make it so a regtest once more.
>
> Some of the increases in counts in the tree dumps look alarming. They
> are however just a reflection of the number of derived types in some
> of the tests and are due to the auxiliary vtable functions.
>
> Bootstrapped and regtested on FC23/x86_64 - OK for trunk and then 7- branch?
>
> Paul
>
> 2017-11-01  Paul Thomas  <pault@gcc.gnu.org>
>
>     PR fortran/81447
>     PR fortran/82783
>     * resolve.c (resolve_component): There is no need to resolve
>     the components of a use associated vtype.
>     (resolve_fl_derived): Unconditionally generate a vtable for any
>     module derived type, as long as the standard is F2003 or later
>     and it is not a vtype or a PDT template.
>
> 2017-11-01  Paul Thomas  <pault@gcc.gnu.org>
>
>     PR fortran/81447
>     * gfortran.dg/class_65.f90: New test.
>     * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free
>     count from 18 to 21.
>     * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free
>     count from 32 to 54.
>     * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free
>     count from 4 to 10.
>     * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free
>     count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to
>     3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from
>     2 to 5.
>     * gfortran.dg/finalize_28.f90: Increase builtin_free
>     count from 3 to 6.
>     * gfortran.dg/move_alloc_15.f90: Increase builtin_free and
>     builtin_malloc counts from 11 to 14.
>     * gfortran.dg/typebound_proc_27.f03: Increase builtin_free
>     count from 7 to 10. Likewise builtin_malloc from 12 to 15.



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Attachment: resubmit.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]