[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-11
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.1, 5.0
           Severity|major                       |normal

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed on 4.9.1 and trunk (5.0).

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[matthew.hambley at metoffice dot gov.uk]

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

matthew.hambley at metoffice dot gov.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthew.hambley at metoffice dot g
                   |                            |ov.uk

--- Comment #2 from matthew.hambley at metoffice dot gov.uk ---
Created attachment 34067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34067&action=edit
Minimal test case for the issue under v4.9.2.

I just stumbled across this in v4.9.2. Attached is a minimal test case.

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[matthew.hambley at metoffice dot gov.uk]

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

--- Comment #3 from matthew.hambley at metoffice dot gov.uk ---
(In reply to matthew.hambley from comment #2)
> Created attachment 34067 [details]
> Minimal test case for the issue under v4.9.2.
> 
> I just stumbled across this in v4.9.2. Attached is a minimal test case.

And I should have included the compiler output:

$ gfortran -Wall -Wextra stringalloc.f90 
stringalloc.f90: In function ‘test’:
stringalloc.f90:20:0: internal compiler error: in gimplify_expr, at
gimplify.c:8538
     allocate( character( len=len_trim( thing ) ) :: local%thing )
 ^
0x80569e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:8538
0x802929 gimplify_modify_expr
    ../../gcc-4.9.2/gcc/gimplify.c:4510
0x804b67 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:7627
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x805033 gimplify_statement_list
    ../../gcc-4.9.2/gcc/gimplify.c:1432
0x805033 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:8042
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x806e1b gimplify_bind_expr
    ../../gcc-4.9.2/gcc/gimplify.c:1099
0x80438e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:7824
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x805033 gimplify_statement_list
    ../../gcc-4.9.2/gcc/gimplify.c:1432
0x805033 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:8042
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x80408a gimplify_and_add
    ../../gcc-4.9.2/gcc/gimplify.c:385
0x80408a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:7964
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x806e1b gimplify_bind_expr
    ../../gcc-4.9.2/gcc/gimplify.c:1099
0x80438e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
    ../../gcc-4.9.2/gcc/gimplify.c:7824
0x806586 gimplify_stmt(tree_node**, gimple_statement_base**)
    ../../gcc-4.9.2/gcc/gimplify.c:5373
0x80743a gimplify_body(tree_node*, bool)
    ../../gcc-4.9.2/gcc/gimplify.c:8734
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-467934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 21 12:38:04 2014
Return-Path: <gcc-bugs-return-467934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9414 invoked by alias); 21 Nov 2014 12:38:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 8963 invoked by uid 48); 21 Nov 2014 12:37:58 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
Date: Fri, 21 Nov 2014 12:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64012-4-tQGneamNri@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64012-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64012-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg02406.txt.bz2
Content-length: 448

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd012

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please report to linaro.

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fmartinez at gmv dot com

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 64125 has been marked as a duplicate of this bug. ***

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error

[vehre at gcc dot gnu.org]

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

--- Comment #5 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/63230] allocation of deferred length character as derived type component causes internal compiler error

[vehre at gcc dot gnu.org]

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

--- Comment #6 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/63230] allocation of deferred length character as derived type component causes internal compiler error

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

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

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