[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 6 Mar 2017, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894
> 
>             Bug ID: 79894
>            Summary: [5/6/7 Regression] ICE in gfc_add_modify_loc, at
>                     fortran/trans.c:159
>            Product: gcc
>            Version: 7.0
>             Status: UNCONFIRMED
>           Keywords: ice-on-valid-code
>           Severity: normal
>           Priority: P3
>          Component: tree-optimization
>           Assignee: unassigned at gcc dot gnu.org
>           Reporter: marxin at gcc dot gnu.org
>                 CC: rguenth at gcc dot gnu.org
>   Target Milestone: ---
> 
> Starting from r217421, we ICE on:
> 
> $ gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90
>  
> -c
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90:35:0:
> 
>    z4 = asin(z4) ! { dg-error "Fortran 2008: COMPLEX argument" }
> 
> internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
> 0x73e520 gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*, 
> tree_node*)
>         ../../gcc/fortran/trans.c:158
> 0x7783b1 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
> bool)
>         ../../gcc/fortran/trans-expr.c:8793
> 0x7899ea gfc_trans_assignment_1
>         ../../gcc/fortran/trans-expr.c:10064
> 0x73ec87 trans_code
>         ../../gcc/fortran/trans.c:1817
> 0x76fce8 gfc_generate_function_code(gfc_namespace*)
>         ../../gcc/fortran/trans-decl.c:6306
> 0x6f7890 translate_all_program_units
>         ../../gcc/fortran/parse.c:6070
> 0x6f7890 gfc_parse_file()
>         ../../gcc/fortran/parse.c:6270
> 0x73b80f gfc_be_parse_file
>         ../../gcc/fortran/f95-lang.c:204

So the FE builds (and simplifies)

 COMPLEX_EXPR <complex_type 0x7ffff6a85540 complex(kind=4)>
  (REALPART_EXPR (save_expr 0x7ffff6a697e0 <complex_type 0x7ffff68c0000 
complex(kind=4) type <real_type 0x7ffff68bd348 real(kind=4)> (..),
   IMAGPART_EXPR (save_expr 0x7ffff6a697e0
        type <complex_type 0x7ffff68c0000 complex(kind=4) type <real_type 
0x7ffff68bd348 real(kind=4) (..)))

whee you can see the strict type equality asserted does not hold
for the complex expr.

In principle match.pd lacks (convert ...) here for strict GENERIC
type compatibility so I am testing

Index: gcc/match.pd
===================================================================
--- gcc/match.pd        (revision 245908)
+++ gcc/match.pd        (working copy)
@@ -1916,13 +1916,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* COMPLEX_EXPR and REALPART/IMAGPART_EXPR cancellations.  */
 (simplify
  (complex (realpart @0) (imagpart @0))
- @0)
+ (convert @0))
 (simplify
  (realpart (complex @0 @1))
- @0)
+ (convert @0))
 (simplify
  (imagpart (complex @0 @1))
- @1)
+ (convert @1))

 /* Sometimes we only care about half of a complex expression.  */
 (simplify