[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c

[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-09
                 CC|                            |janus at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|[5.0 regression] ICE in     |[5.0 Regression] ICE in
                   |trans-expr.c                |trans-expr.c
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
Here is a reduced test case, which is enough to trigger the ICE:


module muli_trapezium
  implicit none

  type :: muli_trapezium_t
     integer::dim=0
  end type

  type, extends (muli_trapezium_t) :: muli_trapezium_node_class_t
  end type

contains

  pure function get_d_value_array (this) result (subarray)
    class(muli_trapezium_t), intent(in) :: this
    real, dimension(this%dim) :: subarray
  end function

  subroutine set_d_integral (this, subarray)
    class(muli_trapezium_t), intent(inout) :: this
    real, intent(in), dimension(0:this%dim-1) :: subarray
  end subroutine

  subroutine muli_trapezium_list_integrate ()
    class(muli_trapezium_node_class_t), pointer :: node
    call set_d_integral ( node,  get_d_value_array(node) )   ! ICE
  end subroutine

end module


Backtrace:

0x6b8df3 gfc_conv_component_ref
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:1954
0x6b8f4a conv_parent_component_references
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:2020
0x6c3633 gfc_conv_variable
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:2209
0x6c0cba gfc_conv_expr(gfc_se*, gfc_expr*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6882
0x6c22ba gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:3849
0x699bf8 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:794
0x6bf118 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:5347
0x6c0737 gfc_conv_function_expr
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:5938
0x6c0c9a gfc_conv_expr(gfc_se*, gfc_expr*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:6874
0x6a67b3 gfc_add_loop_ss_code
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:2560
0x6a7385 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:4711
0x6a4f5b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:6689
0x6a857e gfc_conv_array_parameter(gfc_se*, gfc_expr*, bool, gfc_symbol const*,
char const*, tree_node**)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-array.c:7184
0x6bc89b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-expr.c:4843
0x6eec1e gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-stmt.c:419
0x69590c trans_code
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:1728
0x6b6723 gfc_generate_function_code(gfc_namespace*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans-decl.c:5842
0x6979d1 gfc_generate_module_code(gfc_namespace*)
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/trans.c:2021
0x651915 translate_all_program_units
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5328
0x651915 gfc_parse_file()
    /home/jweil/gcc/gcc50/trunk/gcc/fortran/parse.c:5538

[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly further reduced:


  implicit none

  type :: muli_trapezium_t
     integer::dim=0
  end type

  type, extends (muli_trapezium_t) :: muli_trapezium_node_class_t
  end type

  class(muli_trapezium_node_class_t), pointer :: node
  print *,get_d_value_array(node)    ! ICE

contains

  function get_d_value_array (this) result (subarray)
    class(muli_trapezium_t), intent(in) :: this
    real, dimension(this%dim) :: subarray
  end function

end

[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |edlinger at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This appeared between revisions r218570 (2014-12-10, compiles) and r218658
(2014-12-12, ICE). Possible candidates are r218584 (pr60718) and r218630
(pr42108), likely r218584. The other commits in the range are for the error
handling machinery.

[Bug fortran/64980] [5.0 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
This cures it:

Index: trans-expr.c
===================================================================
--- trans-expr.c    (révision 220514)
+++ trans-expr.c    (copie de travail)
@@ -4537,6 +4537,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
                      fsym->attr.optional
                      && e->expr_type == EXPR_VARIABLE);
             }
+#if 0
           else if (e->ts.type == BT_CLASS && fsym
                && fsym->ts.type == BT_CLASS
                && !CLASS_DATA (fsym)->as
@@ -4587,6 +4588,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
             }
             }
           else
+#endif
             gfc_conv_expr_reference (&parmse, e);

           /* Catch base objects that are not variables.  */

So yes, r218584 is the cause.
The problem comes from the interface mapping machinery, which locally changes
THIS from class MULTI_TRAPEZIUM_T to MULTI_TRAPEZIUM_NODE_CLASS_T in the call
get_d_value_array(node).
The code from r218584 creates a temporary using the declared type
MULTI_TRAPEZIUM_T, which doesn't match what interface mapping expects.
>From gcc-bugs-return-476466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 13:52:44 2015
Return-Path: <gcc-bugs-return-476466-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20589 invoked by alias); 9 Feb 2015 13:52:44 -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 20478 invoked by uid 55); 9 Feb 2015 13:52:40 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63679] [5 Regression][AArch64] Failure to constant fold.
Date: Mon, 09 Feb 2015 13:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63679-4-g7uWpmSbaP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63679-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63679-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: 2015-02/txt/msg00799.txt.bz2
Content-length: 1402

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

--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?idc679
>
> --- Comment #29 from Tejas Belagod <belagod at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #28)
> > On Mon, 9 Feb 2015, belagod at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?idc679
> > >
> > > --- Comment #27 from Tejas Belagod <belagod at gcc dot gnu.org> ---
> > > We'd want to scalarize this early preferably in SRA as it gives a chance to
> > > passes like vectorization to vectorize more loops. I checked that
> > > sra-max-scalarization-Osize{-Ospeed} had no effect on scalarizing 'a = *.LC0'
> >
> > because SRA can't scalarize 'a = *.LC0'.  But yes, ideally we'd change
> > gimplification to never decompose initializers but have SRA do it.
> > But that's of course not a GCC 5 thing.
> >
> > It has the advantage of splitting the initialization only when it is
> > (likely) profitable and otherwise leave it to the target to decide
> > how to expand the initialization (and it opens up the possibility
> > to directly use a constant-pool entry if the data is readonly).
>
> Which cost function(s) control this profitability of early splitting?

See gimplify_init_constructor and callees.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
            Summary|[5.0 Regression] ICE in     |[5 Regression] ICE in
                   |trans-expr.c                |trans-expr.c

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #4)
> This cures it:

Another way to cure it:

Index: trans-expr.c
===================================================================
--- trans-expr.c    (révision 220514)
+++ trans-expr.c    (copie de travail)
@@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface
       expr->symtree = sym->new_sym;
     else if (sym->expr)
       gfc_replace_expr (expr, gfc_copy_expr (sym->expr));
-    /* Replace base type for polymorphic arguments.  */
-    if (expr->ref && expr->ref->type == REF_COMPONENT
-        && sym->expr && sym->expr->ts.type == BT_CLASS)
-      expr->ref->u.c.sym = sym->expr->ts.u.derived;
       }

       /* ...and to subexpressions in expr->value.  */
>From gcc-bugs-return-476501-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 15:58:59 2015
Return-Path: <gcc-bugs-return-476501-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29516 invoked by alias); 9 Feb 2015 15:58:59 -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 29431 invoked by uid 55); 9 Feb 2015 15:58:55 -0000
From: "kuehro at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgcc/61309] cilk-plus tests fail with: hidden symbol `__cpu_model' in /x/gcc/testsuite/g++/../../libgcc.a(cpuinfo.o) is referenced by DSO
Date: Mon, 09 Feb 2015 15:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgcc
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kuehro at gmx dot de
X-Bugzilla-Status: UNCONFIRMED
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:
Message-ID: <bug-61309-4-o4EUDPq7LS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61309-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61309-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: 2015-02/txt/msg00834.txt.bz2
Content-length: 923

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

--- Comment #3 from Kai-Uwe Eckhardt <kuehro at gmx dot de> ---
Hello John,

> FYI, this is still happening.
> So if/when DragonFly features libgcc_s from 5.0 in base, these errors will go
> away?

To be honest I am not quite sure, but I think it is not the presence of
libgcc_s.so itself but the presence of __cpu_model within. Mabey a
linker script similar to the one in PR 40134 would help.


> If so, doesn't that imply the linking is making assumptions it should not make?

Cilk is Linux centric in other places as as well, so I wouldn't wonder. I
don't have a Linux system at hand right now to compare the defined symbols.

Actually I am giving up on gcc and NetBSD. I have tried to push some changes
upstream but gcc has become too complex for my skills and the number of
upstream
NetBSD developers is too low. Good luck with Dragonfly.

Kind regards,

Kai-Uwe

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Mikael Morin from comment #5)
> (In reply to Mikael Morin from comment #4)
> > This cures it:
> 
> Another way to cure it:
> 
> Index: trans-expr.c
> ===================================================================
> --- trans-expr.c	(révision 220514)
> +++ trans-expr.c	(copie de travail)
> @@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface
>  	  expr->symtree = sym->new_sym;
>  	else if (sym->expr)
>  	  gfc_replace_expr (expr, gfc_copy_expr (sym->expr));
> -	/* Replace base type for polymorphic arguments.  */
> -	if (expr->ref && expr->ref->type == REF_COMPONENT
> -	    && sym->expr && sym->expr->ts.type == BT_CLASS)
> -	  expr->ref->u.c.sym = sym->expr->ts.u.derived;
>        }
>  
>        /* ...and to subexpressions in expr->value.  */

unfortunately this would make class_41.f03 fail.

class_41.f03 is very similar to this test case.

Both do deliberately pass a subclass to the base class,
just class_41.f03 uses identical pointer/allocatable attributes,
while this test case uses different pointer/allocatable attributes,
and this satisfies the condition in r218584.

However the intention of r214584 was to avoid aliasing
violations between class objects of the _same_ class type and different
pointer/allocatable attributes.  Additionally to cause problems
(at least on ARM, but in theory on any target too...)
the class with the wrong attributes must be passed to a subroutine.
See PR60718 for details.


I see no aliasing problems in this example if we avoid to cast
the class type to the destination class type.  And the value is
not passed to a subroutine.

So I would add the following to the condition that make the
new block only execute if both objects are of the same class.


Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c    (revision 220543)
+++ gcc/fortran/trans-expr.c    (working copy)
@@ -4539,6 +4539,8 @@
             }
           else if (e->ts.type == BT_CLASS && fsym
                && fsym->ts.type == BT_CLASS
+               && CLASS_DATA (fsym)->ts.u.derived
+                  == CLASS_DATA (e)->ts.u.derived
                && !CLASS_DATA (fsym)->as
                && !CLASS_DATA (e)->as
                && (CLASS_DATA (fsym)->attr.class_pointer


With this patch all fortran test cases pass on x86_64.
And the ICE goes away in the reduced test example.
Does it work for you?
>From gcc-bugs-return-477069-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 12 21:21:33 2015
Return-Path: <gcc-bugs-return-477069-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18791 invoked by alias); 12 Feb 2015 21:21:33 -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 18747 invoked by uid 48); 12 Feb 2015 21:21:29 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
Date: Thu, 12 Feb 2015 21:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64317-4-2WJBZmlOjI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64317-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64317-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: 2015-02/txt/msg01402.txt.bz2
Content-length: 664

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
And for GCC 5, ISTM the question that hasn't been answered, particularly with
regard to the second reproducer is whether or this is a regression for the
overall performance of that code.

It's certainly possible that IRA determined that %ebx was better used to hold a
different value and that the PIC register might end up in a call-clobbered
register.  If the object in %ebx is heavily used, the benefits of keeping that
value in %ebx may outweigh the cost of having the PIC value in a different
register (say perhaps one that is call-clobbered).

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> With this patch all fortran test cases pass on x86_64.
> And the ICE goes away in the reduced test example.
> Does it work for you?

It works for me for all the tests in this PR, without regression, and without
visible problem in my own tests. Thanks.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 34751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34751&action=edit
Proposed Fix

OK, now I see the original test case exposes an aliasing violation
when node is passed to node._vptr->get_d_position(&node)

struct __class_muli_trapezium_Muli_trapezium_node_class_t_p node;

but

muli_trapezium_get_d_position (struct __class_muli_trapezium_Muli_trapezium_t_t
& restrict this)

So my previous patch is just not aggressive enough.

How about the attached patch, which looks like it simplifies the code.

I will post this new patch, which combines Mikael's patch and
fixes class_41.f03 and these test cases, by rewriting _all_ cases
where the class type is different, either because of different
attributes, or because of a derived base type even when the other
attributes are identical as in class_41.f03.

The call of get_d_position is now rewritten as follows:

  this.22 = VIEW_CONVERT_EXPR<struct
__class_muli_trapezium_Muli_trapezium_t_t>(node);
  D.3752 = node._vptr->get_d_position (&this.22);
  this.23 = VIEW_CONVERT_EXPR<struct
__class_muli_trapezium_Muli_trapezium_t_t>(node);
  D.3754 = &this.23;
  D.3755 = D.3754->_data->dim;
  D.3756 = (integer(kind=8)) D.3755 + -1;


Given the complexity of the generated code, it would be
good to have a positive test, instead of a compile-only test.

Could you please propose a positive test case for this?

Thanks,
Bernd.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #8)
> I will post this new patch, which combines Mikael's patch and
> fixes class_41.f03 and these test cases,

Actually, my patch was not supposed to be a real fix, rather a tip telling
where to look at.

(In reply to Bernd Edlinger from comment #8)
> The call of get_d_position is now rewritten as follows:
> 
>   this.22 = VIEW_CONVERT_EXPR<struct
> __class_muli_trapezium_Muli_trapezium_t_t>(node);
>   D.3752 = node._vptr->get_d_position (&this.22);
>   this.23 = VIEW_CONVERT_EXPR<struct
> __class_muli_trapezium_Muli_trapezium_t_t>(node);
>   D.3754 = &this.23;
>   D.3755 = D.3754->_data->dim;
>   D.3756 = (integer(kind=8)) D.3755 + -1;
> 
It seems to me that the second VIEW_CONVERT_EXPR is not necessary.
If that's correct, there should be two references, one through
VIEW_CONVERT_EXPR for the function call, and one without VIEW_CONVERT_EXPR to
use for interface mapping (to get the resulting size).

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Mikael Morin from comment #9)
> 
> (In reply to Bernd Edlinger from comment #8)
> > The call of get_d_position is now rewritten as follows:
> > 
> >   this.22 = VIEW_CONVERT_EXPR<struct
> > __class_muli_trapezium_Muli_trapezium_t_t>(node);
> >   D.3752 = node._vptr->get_d_position (&this.22);
> >   this.23 = VIEW_CONVERT_EXPR<struct
> > __class_muli_trapezium_Muli_trapezium_t_t>(node);
> >   D.3754 = &this.23;
> >   D.3755 = D.3754->_data->dim;
> >   D.3756 = (integer(kind=8)) D.3755 + -1;
> > 
> It seems to me that the second VIEW_CONVERT_EXPR is not necessary.
> If that's correct, there should be two references, one through
> VIEW_CONVERT_EXPR for the function call, and one without VIEW_CONVERT_EXPR
> to use for interface mapping (to get the resulting size).

Yes, but I have no idea how to know how the result is going to be
used, in gfc_conv_procedure_call, line 4544.  If you have an idea
how to detect this case, that would be great.

If if is later passed to a subroutine, it should be a VIEW_CONVERT_EXPR,
But if it is later fixed in gfc_apply_interface_mapping_to_expr,
then it would be better to avoid the VIEW_CONVERT_EXPR in the first place.

Until yesterday, I thought the result is always used in a procedure call
context, and I thought we only have aliasing violations on different
variations of the same principal class, but that was also wrong.

The good news is:
The code should be correct this way, and if we are lucky the optimizer
will do its job and optimize that redundant assignment away.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 34755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34755&action=edit
Another proposed  fix

(In reply to Bernd Edlinger from comment #10)
> Yes, but I have no idea how to know how the result is going to be
> used, in gfc_conv_procedure_call, line 4544.  If you have an idea
> how to detect this case, that would be great.

It is used as argument to the procedure, and also added to the interface
mapping mechanism through gfc_add_interface_mapping.
>From there, it is dropped if the resulting size can be determined by other
means; otherwised it is used to set the array result bounds.

The attached patch (untested so far) makes a copy of the reference before
passing it through VIEW_CONVERT_EXPR.
It avoids the second V_C_E at least.

> 
> Until yesterday, I thought the result is always used in a procedure call
> context, and I thought we only have aliasing violations on different
> variations of the same principal class, but that was also wrong.
What I don't understand is why there isn't something alike needed for non-class
arrays?  They also use different variations of the same principal class, don't
they?

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
With any of the patches the first test for pr64230 fails at run time with

At line 35 of file pr64230.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 't'

but the test gfortran.dg/class_allocate_18.f90 succeeds.

In addition Bernd's patch fixes/hides the ICE for pr61960.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 34757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34757&action=edit
Yet another attempt using TYPE_CANONICAL

this tries to remove any use of VIEW_CONVERT_EXPR by setting (well, trying to
set) the same TYPE_CANONICAL for the different class containers.  And hope the
middle-end is satisfied with that.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> ---
Bernd, do you have a reliable way to test a patch, checking for aliasing
violations?

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 34758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34758&action=edit
Updated patch that also fixes pr64230.f90

(In reply to Dominique d'Humieres from comment #12)
> With any of the patches the first test for pr64230 fails at run time with
> 
> At line 35 of file pr64230.f90
> Fortran runtime error: Attempt to DEALLOCATE unallocated 't'
> 
> but the test gfortran.dg/class_allocate_18.f90 succeeds.
> 
> In addition Bernd's patch fixes/hides the ICE for pr61960.

I think this updated patch fixes all mentioned test cases.
Especially pr64230.f90.  In this example the condition
CLASS_DATA (fsym) != CLASS_DATA (e) evaluates to TRUE,
but fsym->ts.u.derived->name and e->ts.u.derived->name
are the same, something like "__class_m_T4_a".

But s from pr64230.f90 has an intent(out) parameter.

Entering this code path for an intent(out) parameter
means complete disaster, because it does only copy the value
to the destination and not in the reverse direction.

Hopefully these types are really identical also for the back end...

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #16 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Mikael Morin from comment #14)
> Bernd, do you have a reliable way to test a patch, checking for aliasing
> violations?

No, all I can do is run the test suite on my armv7l-unknown-linux-gnueabihf
target.  The problem with the alias violations is as big as an ice berg,
but it only made one single test case fail on the ARMv7 target:
select_type_4.f90, see pr60718.

Regarding your patch with TYPE_CANONICAL: interesting idea.

Although it is completely invisible on -fdump-tree-original,
the problematic assembler section changes on the reduced test case
select_type_4a.f90.  I have only a cross-compiler at the moment, so I can not
tell, if the code would work in reality, but it looks like it should.

I am not sure if I find time to test your patch on the real target next week.

However there are many test cases failing on x86_64 at the moment:


you can ignore the class_alias.f90 failures, because this test case
works more or less like a module test for r218584, so if that is removed
the test case makes no sense any more.

but there are many regressions, which would need to be fixed before
it makes sense to test anything on the ARMv7 target:
FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (internal compiler error)
FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
UNRESOLVED: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib  -O2 
-lcaf_single -latomic compilation failed to produce executable
FAIL: gfortran.dg/class_optional_1.f90   -Os  execution test
FAIL: gfortran.dg/move_alloc_13.f90   -Os  execution test
FAIL: gfortran.dg/select_type_26.f03   -O2  execution test
FAIL: gfortran.dg/select_type_26.f03   -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/select_type_26.f03   -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/select_type_26.f03   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/select_type_26.f03   -O3 -g  execution test
FAIL: gfortran.dg/sizeof_4.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O1  compilation failed to produce
executable
FAIL: gfortran.dg/sizeof_4.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O2  compilation failed to produce
executable
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer  (internal compiler
error)
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer  (test for excess
errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer  compilation
failed to produce executable
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer -funroll-loops 
(internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer -funroll-loops  (test
for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer -funroll-loops 
compilation failed to produce executable
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/sizeof_4.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -O3 -g  (test for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -O3 -g  compilation failed to produce
executable
FAIL: gfortran.dg/sizeof_4.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/sizeof_4.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/sizeof_4.f90   -Os  compilation failed to produce
executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer  (test
for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer 
compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer  (test
for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer 
compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_1.f03   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer 
(test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
 compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_17.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_17.f90   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer 
(test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
 compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_18.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_18.f90   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer 
(test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
 compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_19.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_19.f90   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer 
(test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
 compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_21.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_21.f90   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_3.f03   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_3.f03   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_3.f03   -Os  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O1  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O1  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O2  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O2  compilation failed
to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer  (test
for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer 
compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-loops  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  compilation failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -g  (internal compiler
error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -g  (test for excess
errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -O3 -g  compilation
failed to produce executable
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_5.f90   -Os  (test for excess errors)
UNRESOLVED: gfortran.dg/unlimited_polymorphic_5.f90   -Os  compilation failed
to produce executable

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I think this updated patch fixes all mentioned test cases.

Confirmed, bootstrapped and regtested cleanly.

> but there are many regressions, which would need to be fixed before
> it makes sense to test anything on the ARMv7 target:
> FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib  -O2  -lcaf_single -latomic
> (internal compiler error)
> ...

Are these failures regressions caused by your patch?

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #18 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Dominique d'Humieres from comment #17)
> > I think this updated patch fixes all mentioned test cases.
> 
> Confirmed, bootstrapped and regtested cleanly.
> 
> > but there are many regressions, which would need to be fixed before
> > it makes sense to test anything on the ARMv7 target:
> > FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=lib  -O2  -lcaf_single -latomic
> > (internal compiler error)
> > ...
> 
> Are these failures regressions caused by your patch?

No, I was refering to the patch from comment#13.

My latest patch causes no visible regressions, including the test cases you
mentioned.

BTW: should we add the original test case from pr64230 the test suite, because
class_allocate_18.f90 failed to spot this regression?

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> BTW: should we add the original test case from pr64230 the test suite,
> because class_allocate_18.f90 failed to spot this regression?

Why not? Better safe than sorry. Note that the original test does not suffer
the problem reported in pr64921.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #20 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Dominique d'Humieres from comment #12)
> In addition Bernd's patch fixes/hides the ICE for pr61960.

this pr is fixed by this hunk alone:
--- gcc/fortran/trans-expr.c    (revision 220662)
+++ gcc/fortran/trans-expr.c    (working copy)
@@ -3783,10 +3783,6 @@ gfc_apply_interface_mapping_to_expr (gfc_interface
          expr->symtree = sym->new_sym;
        else if (sym->expr)
          gfc_replace_expr (expr, gfc_copy_expr (sym->expr));
-       /* Replace base type for polymorphic arguments.  */
-       if (expr->ref && expr->ref->type == REF_COMPONENT
-           && sym->expr && sym->expr->ts.type == BT_CLASS)
-         expr->ref->u.c.sym = sym->expr->ts.u.derived;
       }

       /* ...and to subexpressions in expr->value.  */

I verified the generated code, not only the ICE is gone, but
the code seems work.

So I'd declare pr61960 to be a duplicate of this PR.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[edlinger at gcc dot gnu.org]

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

--- Comment #21 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Author: edlinger
Date: Sun Feb 22 19:38:53 2015
New Revision: 220899

URL: https://gcc.gnu.org/viewcvs?rev=220899&root=gcc&view=rev
Log:
2015-02-22  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR fortran/64980
        PR fortran/61960
        * trans-expr.c (gfc_apply_interface_mapping_to_expr): Remove mapping
        for component references to class objects.
        (gfc_conv_procedure_call): Compare the class by name.

testsuite:
2015-02-22  Bernd Edlinger  <bernd.edlinger@hotmail.de>

        PR fortran/64980
        PR fortran/61960
        * gfortran.dg/pr61960.f90: New.
        * gfortran.dg/pr64230.f90: New.
        * gfortran.dg/pr64980.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr61960.f90
    trunk/gcc/testsuite/gfortran.dg/pr64230.f90
    trunk/gcc/testsuite/gfortran.dg/pr64980.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger <edlinger at gcc dot gnu.org> changed:

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

--- Comment #22 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
fixed on trunk.