[Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[Bug fortran/101123] New: [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[rguenth at gcc dot gnu.org]

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

            Bug ID: 101123
           Summary: [11/12 Regression] Invalid code for MAX0 with
                    -fdefault-integer-8
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

> cat TESTN.f 
      IMPLICIT DOUBLE PRECISION (A-H,O-R,T-Z), INTEGER*4 (I-N)
      COMMON KN(100)
      KN(3)=10
      KN(4)=20
      CALL TEST
C
      STOP  
      END
C  _____________________________________________________________________
C
      SUBROUTINE TEST
      IMPLICIT DOUBLE PRECISION (A-H,O-R,T-Z), INTEGER*4 (I-N)
C
      COMMON KN(100)
C
      EQUIVALENCE (KN( 3),M     ), (KN( 4),N     )
      MAXMN=MAX0(M,N)
      RETURN
      END

> ~/install/gcc-11/usr/local/bin/gfortran TESTN.f -c -fdefault-integer-8  -fchecking
TESTN.f:11:21:

   11 |       SUBROUTINE TEST
      |                     ^
Error: invalid types in conversion to integer
integer(kind=8)
integer(kind=4)
_2 = (integer(kind=8)) M.0;
TESTN.f:11: confused by earlier errors, bailing out

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2
      Known to work|                            |10.3.1
           Priority|P3                          |P4
           Keywords|                            |ice-on-valid-code,
                   |                            |needs-bisection, wrong-code

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-06-18
                 CC|                            |anlauf at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Keywords|needs-bisection             |

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-2746-g3c04bd60e56da399a441f73ebb687b5039b9cf3f

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Why on Earth would somebody really want to combine legacy MAX0 with
IMPLICIT INTEGER*4 and -fdefault-integer-8?

Reduced testcase:

      SUBROUTINE TEST
      IMPLICIT INTEGER*4 (I-N)
      MAXMN=MAX0(M,N)
      END

Dump tree:

__attribute__((fn spec (". ")))
void test ()
{
  integer(kind=4) m;
  integer(kind=4) maxmn;
  integer(kind=4) n;

  {
    integer(kind=4) M.0;

    M.0 = m;
    M.0 = MAX_EXPR <n, M.0>;
    maxmn = (integer(kind=4)) (integer(kind=8)) M.0;
  }
}

Is the dump tree inaccurate?  It matches my expectation.

Note: the code compiles with MAX0 replaced by (the generic) MAX.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I think this PR should be closed as invalid.

When using -fdefault_*, it is the user's responsibility to check that the
promotion is compatible with procedure arguments: MAX0 is expecting INTEGER(4)
and is given INTEGER(8).

The code compiles if MAX0 is replaced with the generic function MAX.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Untested potential fix:

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 73b0bcc9dea..e578449995a 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -4147,10 +4147,7 @@ gfc_conv_intrinsic_minmax (gfc_se * se, gfc_expr * expr,
enum tree_code op)
                        build_empty_stmt (input_location));
       gfc_add_expr_to_block (&se->pre, tmp);
     }
-  if (TREE_CODE (type) == INTEGER_TYPE)
-    se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
-  else
-    se->expr = convert (type, mvar);
+  se->expr = convert (type, mvar);
 }

Not sure if there is some cornercase which will get mishandled.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is clearly a FE bug:
gfc_conv_intrinsic_minmax does:
  if (TREE_CODE (type) == INTEGER_TYPE)
    se->expr = fold_build1_loc (input_location, FIX_TRUNC_EXPR, type, mvar);
  else
    se->expr = convert (type, mvar);
and as type (in this kase integer(kind=8)) is INTEGER_TYPE, it creates a
FIX_TRUNC_EXPR.  But that is only valid if mvar has floating point type, which
is not the case here.
Why don't you do se->expr = convert (type, mvar); unconditionally?  That should
create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Why don't you do se->expr = convert (type, mvar); unconditionally?  That
> should
> create FIX_TRUNC_EXPR for the FLOAT_TYPE -> INTEGER_TYPE conversion as well,
> but will handle correctly even INTEGER_TYPE -> INTEGER_TYPE conversions etc.?

Will do.  This also regtests cleanly.

Will prepare a testcase also for the related pr100283 which is fixed with
this change and commit shortly.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:6fc543396345900f460c9fa7121239cb1ebbc3a3

commit r12-1650-g6fc543396345900f460c9fa7121239cb1ebbc3a3
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri Jun 18 19:34:15 2021 +0200

    Fortran - fix conversion to result type for the min/max intrinsic

    gcc/fortran/ChangeLog:

            PR fortran/100283
            PR fortran/101123
            * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
            convert result of min/max to result type.

    gcc/testsuite/ChangeLog:

            PR fortran/100283
            PR fortran/101123
            * gfortran.dg/min0_max0_1.f90: New test.
            * gfortran.dg/min0_max0_2.f90: New test.

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:e5220a731229eaa7be42232c6e9a9dd881fed2b9

commit r11-8624-ge5220a731229eaa7be42232c6e9a9dd881fed2b9
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri Jun 18 19:34:15 2021 +0200

    Fortran - fix conversion to result type for the min/max intrinsic

    gcc/fortran/ChangeLog:

            PR fortran/100283
            PR fortran/101123
            * trans-intrinsic.c (gfc_conv_intrinsic_minmax): Unconditionally
            convert result of min/max to result type.

    gcc/testsuite/ChangeLog:

            PR fortran/100283
            PR fortran/101123
            * gfortran.dg/min0_max0_1.f90: New test.
            * gfortran.dg/min0_max0_2.f90: New test.

    (cherry picked from commit 6fc543396345900f460c9fa7121239cb1ebbc3a3)

[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and on 11-branch.  Closing.