This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670
- From: "janus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Jan 2010 13:32:22 -0000
- Subject: [Bug fortran/42888] [4.5 Regression] ICE in fold_convert_loc, at fold-const.c:2670
- References: <bug-42888-6318@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #9 from janus at gcc dot gnu dot org 2010-01-28 13:32 -------
(In reply to comment #7)
> While for the old rev. 'type' and 'orig' are both
> INTEGER_TYPE, 'orig' is REAL_TYPE on current trunk. I'll try to find out how
> that comes about.
Got it. Previously the constructor was created already at resolution stage and
was then resolved by 'resolve_structure_cons', which takes care of type
conversions. Now the constructor is created at translation stage, therefore the
resolution is missing (resolve_structure_cons is never called) and the type
comes out wrong in our example.
Here is a simple patch which removes the ICE:
Index: gcc/fortran/trans-stmt.c
===================================================================
--- gcc/fortran/trans-stmt.c (revision 156258)
+++ gcc/fortran/trans-stmt.c (working copy)
@@ -4180,6 +4180,7 @@ gfc_trans_allocate (gfc_code * code)
else if (expr->ts.type == BT_DERIVED
&& (init_e = gfc_default_initializer (&expr->ts)))
{
+ gfc_resolve_expr (init_e);
tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr),
init_e, true);
gfc_add_expr_to_block (&block, tmp);
--
janus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2010-01-28 04:27:20 |2010-01-28 13:32:22
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888