[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2016-11-16 Thread janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2016-01-05 Thread vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from vehre at gcc dot gnu.org ---
No complaints so far, closing.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-29 Thread vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

--- Comment #10 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Dec 29 13:20:37 2015
New Revision: 231992

URL: https://gcc.gnu.org/viewcvs?rev=231992=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2015-12-29  Andre Vehreschild  

PR fortran/69011
* gfortran.dg/allocate_with_source_16.f90: New test.


gcc/fortran/ChangeLog:

2015-12-29  Andre Vehreschild  

PR fortran/69011
* trans-stmt.c (gfc_trans_allocate): Unwrap a NOP_EXPR to make sure
the actual type of the source=-expr is used when it is of class type.
Furthermore prevent an ICE.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-28 Thread vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #9 from vehre at gcc dot gnu.org ---
Proposed patch: https://gcc.gnu.org/ml/fortran/2015-12/msg00143.html

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gmx dot de

--- Comment #7 from vries at gcc dot gnu.org ---
Andre,

given that you've added the POINTER_PLUS_EXPR test (and other code in the
condition) in the snippet from comment 5, can you take a look at this PR?

Thanks,
- Tom

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-24 Thread vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #8 from vehre at gcc dot gnu.org ---
Will take a lot as soon as possible.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

--- Comment #5 from vries at gcc dot gnu.org ---
There's a bit of code in gfc_trans_allocate:
...
  if (code->expr3 && !code->expr3->mold)
{
  /* Initialization via SOURCE block (or static default initializer).
 Classes need some special handling, so catch them first.  */
  if (expr3 != NULL_TREE
  && TREE_CODE (expr3) != POINTER_PLUS_EXPR
  && code->expr3->ts.type == BT_CLASS
  && (expr->ts.type == BT_CLASS
  || expr->ts.type == BT_DERIVED))
{
  /* copy_class_to_class can be used for class arrays, too.
 It just needs to be ensured, that the decl_saved_descriptor
 has a way to get to the vptr.  */
  tree to;
  to = VAR_P (se.expr) ? se.expr : TREE_OPERAND (se.expr, 0);
  tmp = gfc_copy_class_to_class (expr3, to,
 nelems, upoly_expr);
}
...

Without r229621, we have:
...
(gdb) call debug_generic_expr (expr3)
(struct integrand *) previous->_data.data + (sizetype) ((previous->_data.offset
+ (integer(kind=8)) self->_data->steps * previous->_data.dim[0].stride) *
(integer(kind=8)) previous->_vptr->_size)
(gdb) p expr3.base.code
$10 = POINTER_PLUS_EXPR
...
and the gfc_copy_class_to_class is not triggered.

With r229621, we have:
...
(gdb) call debug_generic_expr (expr3)
(struct integrand *) (previous->_data.data + (sizetype)
((previous->_data.offset + (integer(kind=8)) self->_data->steps *
previous->_data.dim[0].stride) * (integer(kind=8)) previous->_vptr->_size))
(gdb) p expr3.base.code
$1 = NOP_EXPR
...
and the gfc_copy_class_to_class is triggered, and we hit the assert.

So AFAIU, r229621 inhibits folding in this case. That looks not incorrect to
me.

I've got no idea what the POINTER_PLUS_EXPR test in the bit above is trying to
achieve (and more generally, I've got little knowledge of fortran, and no
knowledge of the fortran frontend), so I've got no idea how this assert should
be fixed.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #4)
> Marking as blocking PR 67779 because we need to fix this to get to the
> wrong-code issue in that PR again.

I suspect this PR is simply a duplicate of the other PR, and that there is no
blocking relation.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

Thomas Koenig  changed:

   What|Removed |Added

 Blocks||67779

--- Comment #4 from Thomas Koenig  ---
Marking as blocking PR 67779 because we need to fix this to get to the
wrong-code issue in that PR again.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
[Bug 67779] Strange ordering with strings in extended object

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-23 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from vries at gcc dot gnu.org ---
Sounds similar to PR67779

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-22 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-22
  Known to work||5.3.0
Summary|[OOP] ICE in|[6 Regression] [OOP] ICE in
   |gfc_advance_chain for   |gfc_advance_chain for
   |ALLOCATE with SOURCE|ALLOCATE with SOURCE
 Ever confirmed|0   |1
  Known to fail||6.0

--- Comment #1 from Dominique d'Humieres  ---
The test compiles with trunk (6.0) at revision r229620 (plus two patches) and
gives the ICE at r229621 (plus two patches) or with a clean r229631.

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

2015-12-22 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011

Thomas Koenig  changed:

   What|Removed |Added

 CC||tom at codesourcery dot com

--- Comment #2 from Thomas Koenig  ---
Tom,

r229621 was yours.  Any idea what could have brought this about?