[Bug fortran/64137] New: Fortran FE builds invalid GENERIC

[Bug fortran/64137] New: Fortran FE builds invalid GENERIC

[rguenth at gcc dot gnu.org]

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

            Bug ID: 64137
           Summary: Fortran FE builds invalid GENERIC
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

#6  0x000000000085f420 in gfc_conv_intrinsic_minmaxloc (se=0x7fffffffd150, 
    expr=0x235ba70, op=GT_EXPR)
    at /space/rguenther/tramp3d/trunk/gcc/fortran/trans-intrinsic.c:3734
(gdb) l
3729         possible value is HUGE in both cases.  */
3730      if (op == GT_EXPR)
3731        tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE
(tmp), tmp);
3732      if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
3733        tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp),
tmp,
3734                               build_int_cst (type, 1));

the body of the 2nd if builds REAL_CST - INTEGER_CST for at least
gfortran.dg/maxloc_2.f90 at -O1+.  Currently it is lucky that fold-const.c

10523         /* A - B -> A + (-B) if B is easily negatable.  */
10524         if (negate_expr_p (arg1)
10525             && !TYPE_OVERFLOW_SANITIZED (type)
(gdb) l
10526             && ((FLOAT_TYPE_P (type)
10527                  /* Avoid this transformation if B is a positive
REAL_CST.  */
10528                  && (TREE_CODE (arg1) != REAL_CST
10529                      ||  REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1))))
10530                 || INTEGRAL_TYPE_P (type)))
10531           return fold_build2_loc (loc, PLUS_EXPR, type,
10532                               fold_convert_loc (loc, type, arg0),
10533                               fold_convert_loc (loc, type,
10534                                                 negate_expr (arg1)));

applies as that fold_convert()s to REAL after negating the integer, hiding
this bug.  When I move that to match.pd patterns that no longer happens,
but we simply get -Huge + -1 with bogus types here.

Not sure what is intended here (integer Huge or Float 1).

[Bug fortran/64137] Fortran FE builds invalid GENERIC

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-12-01
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Index: gcc/fortran/trans-intrinsic.c
===================================================================
--- gcc/fortran/trans-intrinsic.c       (revision 218211)
+++ gcc/fortran/trans-intrinsic.c       (working copy)
@@ -3729,7 +3729,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * s
      possible value is HUGE in both cases.  */
   if (op == GT_EXPR)
     tmp = fold_build1_loc (input_location, NEGATE_EXPR, TREE_TYPE (tmp), tmp);
-  if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
+  if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER)
     tmp = fold_build2_loc (input_location, MINUS_EXPR, TREE_TYPE (tmp), tmp,
                           build_int_cst (type, 1));


works for me.  So I suppose this is a wrong-code bug as we shouldn't have
subtracted 1 off -Huge (what's that anyway?)  But then is "integer -Huge"
C INT_MIN + 1?

Anyway, testing the above.

[Bug fortran/64137] Fortran FE builds invalid GENERIC

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> -  if (op == GT_EXPR && expr->ts.type == BT_INTEGER)
> +  if (op == GT_EXPR && arrayexpr->ts.type == BT_INTEGER)
> works for me.

Looks good to me.  Thanks for the patch and debugging!


[Seems to be a copy'n'paste error from gfc_conv_intrinsic_minmaxval, which
returns the value (= int or float) such that expr->ts.type works; the code in
gfc_conv_intrinsic_minmaxloc return a location which is always an int.]



> So I suppose this is a wrong-code bug as we shouldn't have
> subtracted 1 off -Huge (what's that anyway?)  But then is "integer -Huge"
> C INT_MIN + 1?

HUGE(variable)  is a function which returns the largest possible value for that
variable, i.e. MAX_INT for a default-kind integer or FLT_MAX for a default-kind
real variable.

For MAXLOC, one starts with "val = <smallest possible value>", which is MIN_INT
== -MAX_INT - 1 == -HUGE() - 1 for int or FLT_MIN == -HUGE() for real with
-ffinite-math or otherwise -INF for reals.

[Bug fortran/64137] Fortran FE builds invalid GENERIC

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Dec  2 08:50:57 2014
New Revision: 218259

URL: https://gcc.gnu.org/viewcvs?rev=218259&root=gcc&view=rev
Log:
2014-12-02  Richard Biener  <rguenther@suse.de>

    PR fortran/64137
    * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Check
    proper expressions type, use proper type for computing
    -Huge - 1.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/64137] Fortran FE builds invalid GENERIC

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk.