[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vehre at gcc dot gnu.org

--- Comment #1 from vehre at gcc dot gnu.org ---
This bug does not depend on the optimization level. It segfaults reliably with
-O0 (-g), too.

The reason for the segfault from looking at the tree dump seems to be, that the
vptr->copy() routine is called with two arguments only, but the routine stored
in vptr->copy for copying a character-array is expecting 4 arguments (the
pointers to the array starts and the length of the data).

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-26
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Per comment 1 marked as NEW. On x86_64-apple-darwin14, I see the segmentation
fault with -m32 only and it depends on the version, optimization level, and the
"state" of the machine (erratic fault).

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #3 from vehre at gcc dot gnu.org ---
Fix available with:

https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html
https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html
https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 24 10:28:48 2015
New Revision: 221621

URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog

2015-03-24  Andre Vehreschild  <vehre@gmx.de>

    PR fortran/64787
    PR fortran/57456
    PR fortran/63230
    * class.c (gfc_add_component_ref):  Free no longer needed
    ref-chains to prevent memory loss.
    (find_intrinsic_vtab): For deferred length char arrays or
    unlimited polymorphic objects, store the size in bytes of one
    character in the size component of the vtab.
    * gfortran.h: Added gfc_add_len_component () define.
    * trans-array.c (gfc_trans_create_temp_array): Switched to new
    function name for getting a class' vtab's field.
    (build_class_array_ref): Likewise.
    (gfc_array_init_size): Using the size information from allocate
    more consequently now, i.e., the typespec of the entity to
    allocate is no longer needed.  This is to address the last open
    comment in PR fortran/57456.
    (gfc_array_allocate): Likewise.
    (structure_alloc_comps): gfc_copy_class_to_class () needs to
    know whether the class is unlimited polymorphic.
    * trans-array.h: Changed interface of gfc_array_allocate () to
    reflect the no longer needed typespec.
    * trans-expr.c (gfc_find_and_cut_at_last_class_ref): New.
    (gfc_reset_len): New.
    (gfc_get_class_array_ref): Switch to new function name for
    getting a class' vtab's field.
    (gfc_copy_class_to_class):  Added flag to know whether the class
    to copy is unlimited polymorphic.  Adding _len dependent code
    then, which calls ->vptr->copy () with four arguments adding
    the length information ->vptr->copy(from, to, from_len, to_cap).
    (gfc_conv_procedure_call): Switch to new function name for
    getting a class' vtab's field.
    (alloc_scalar_allocatable_for_assignment): Use the string_length
    as computed by gfc_conv_expr and not the statically backend_decl
    which may be incorrect when ref-ing.
    (gfc_trans_assignment_1): Use the string_length variable and
    not the rse.string_length.  The former has been computed more
    generally.
    * trans-intrinsic.c (gfc_conv_intrinsic_sizeof): Switch to new
    function name for getting a class' vtab's field.
    (gfc_conv_intrinsic_storage_size): Likewise.
    (gfc_conv_intrinsic_transfer): Likewise.
    * trans-stmt.c (gfc_trans_allocate): Restructured to evaluate
    source=expr3 only once before the loop over the objects to
    allocate, when the objects are not arrays. Doing correct _len
    initialization and calling of vptr->copy () fixing PR 64787.
    (gfc_trans_deallocate): Reseting _len to 0, preventing future
    errors.
    * trans.c (gfc_build_array_ref): Switch to new function name
    for getting a class' vtab's field.
    (gfc_add_comp_finalizer_call): Likewise.
    * trans.h: Define the prototypes for the gfc_class_vtab_*_get ()
    and gfc_vptr_*_get () functions.
    Added gfc_find_and_cut_at_last_class_ref () and
    gfc_reset_len () routine prototype.  Added flag to
    gfc_copy_class_to_class () prototype to signal an unlimited
    polymorphic entity to copy.

gcc/testsuite/ChangeLog

2015-03-24  Andre Vehreschild  <vehre@gmx.de>

    * gfortran.dg/allocate_alloc_opt_13.f90: Added tests for
    source= and mold= expressions functionality.
    * gfortran.dg/allocate_class_4.f90: New test.
    * gfortran.dg/unlimited_polymorphic_20.f90: Added test whether
    copying an unlimited polymorhpic object containing a char array
    to another unlimited polymorphic object respects the _len
    component.
    * gfortran.dg/unlimited_polymorphic_22.f90: Extended to check
    whether deferred length char array allocate works, unlimited
    polymorphic object allocation from a string works and if
    allocating an array of deferred length strings works.
    * gfortran.dg/unlimited_polymorphic_24.f03: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_class_4.f90
    trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_24.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-array.h
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_13.f90
    trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_20.f90
    trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_22.f90

[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from vehre at gcc dot gnu.org ---
Fixed with commit r221621.