PR fortran/95053 - division by zero constants

Message ID trinity-fe8a9ba7-0acd-4402-aa7e-44cb3c36bc43-1589574837373@3c-app-gmx-bap58
State New
Headers show
Series
  • PR fortran/95053 - division by zero constants
Related show

Commit Message

Harald Anlauf May 15, 2020, 8:33 p.m.
Here's a new attempt to finally fix this PR and any known fallout.

In order to handle division by zero in declarations, but still accept the
code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk
that was added to fix PR94399, and deferred the handling to a later stage.

One case regarding array shapes is handled in variable_decl in decl.c, the
other one regarding PDTs is handled in gfc_get_pdt_instance in the same
file.  While at it, I improved the error message to notify the user if an
expression that should be of INTEGER type isn't.

Regtests with no new failures on x86_64-pc-linux-gnu, after adjusting
error messages for test dec_structure_23.f90.

OK for trunk?

Thanks,
Harald


PR fortran/95053 - division by zero constants

	Partially revert the fix for PR93499.  Replace by checks for valid
	expressions in the declaration of array shape and PDT KIND and LEN
	expressions at a later stage.

gcc/fortran/

2020-05-15  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/95053
	* arith.c (gfc_divide): Revert hunk introduced by patch for
	PR93499.
	* decl.c (variable_decl): Generate error for array shape not being
	an INTEGER constant.
	(gfc_get_pdt_instance): Generate error if KIND or LEN expressions
	in declaration of a PDT instance do not simplify to INTEGER
	constants.

gcc/testsuite/

2020-05-15  Harald Anlauf  <anlauf@gmx.de>

	PR fortran/95053
	* gfortran.dg/dec_structure_23.f90: Adjust to new error messages.
	* gfortran.dg/pr95053_2.f90: New test.
	* gfortran.dg/pr95053_3.f90: New test.

Comments

Hongyu Wang via Gcc-patches May 17, 2020, 10:33 p.m. | #1
Am 15.05.20 um 22:33 schrieb Harald Anlauf:
> Here's a new attempt to finally fix this PR and any known fallout.

> 

> In order to handle division by zero in declarations, but still accept the

> code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk

> that was added to fix PR94399, and deferred the handling to a later stage.

> 

> One case regarding array shapes is handled in variable_decl in decl.c, the

> other one regarding PDTs is handled in gfc_get_pdt_instance in the same

> file.  While at it, I improved the error message to notify the user if an

> expression that should be of INTEGER type isn't.

> 

> Regtests with no new failures on x86_64-pc-linux-gnu, after adjusting

> error messages for test dec_structure_23.f90.

> 

> OK for trunk?


I think this is a good approach (and a better error message, too).

So, OK, and thanks for the patch!

Regards

	Thomas

Patch

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index dd72f44d377..c770569eb81 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1806,38 +1806,6 @@  gfc_multiply (gfc_expr *op1, gfc_expr *op2)
 gfc_expr *
 gfc_divide (gfc_expr *op1, gfc_expr *op2)
 {
-  if (op2 && op2->expr_type == EXPR_CONSTANT)
-    {
-      arith rc = ARITH_OK;
-      switch (op2->ts.type)
-	{
-	case BT_INTEGER:
-	  /* non-integer divided by integer 0 is handled elsewhere.  */
-	  if (mpz_sgn (op2->value.integer) == 0
-	      && op1->ts.type == BT_INTEGER)
-	    rc = ARITH_DIV0;
-	  break;
-	case BT_REAL:
-	  if (mpfr_sgn (op2->value.real) == 0
-	      && flag_range_check == 1)
-	    rc = ARITH_DIV0;
-	  break;
-	case BT_COMPLEX:
-	  if (mpc_cmp_si_si (op2->value.complex, 0, 0) == 0
-	      && flag_range_check == 1)
-	    rc = ARITH_DIV0;
-	  break;
-	default:
-	  /* basic type is non-numeric, handle this elsewhere.  */
-	  break;
-	}
-      if (rc == ARITH_DIV0)
-	{
-	  gfc_seen_div0 = true;
-	  gfc_error ("Division by zero at %L", &op2->where);
-	  return NULL;
-	}
-    }
   return eval_intrinsic_f3 (INTRINSIC_DIVIDE, gfc_arith_divide, op1, op2);
 }

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 9cc81361f43..3ad5559c3ec 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2607,6 +2607,14 @@  variable_decl (int elem)
 	      gfc_free_expr (e);
 	    }

+	  if (not_constant && e->ts.type != BT_INTEGER)
+	    {
+	      gfc_error ("Explicit array shape at %C must be constant of "
+			 "INTEGER type and not %s type",
+			 gfc_basic_typename (e->ts.type));
+	      m = MATCH_ERROR;
+	      goto cleanup;
+	    }
 	  if (not_constant)
 	    {
 	      gfc_error ("Explicit shaped array with nonconstant bounds at %C");
@@ -3741,8 +3749,9 @@  gfc_get_pdt_instance (gfc_actual_arglist *param_list, gfc_symbol **sym,
       if (kind_expr)
 	{
 	  /* Try simplification even for LEN expressions.  */
+	  bool ok;
 	  gfc_resolve_expr (kind_expr);
-	  gfc_simplify_expr (kind_expr, 1);
+	  ok = gfc_simplify_expr (kind_expr, 1);
 	  /* Variable expressions seem to default to BT_PROCEDURE.
 	     TODO find out why this is and fix it.  */
 	  if (kind_expr->ts.type != BT_INTEGER
@@ -3753,6 +3762,12 @@  gfc_get_pdt_instance (gfc_actual_arglist *param_list, gfc_symbol **sym,
 			 gfc_basic_typename (kind_expr->ts.type));
 	      goto error_return;
 	    }
+	  if (kind_expr->ts.type == BT_INTEGER && !ok)
+	    {
+	      gfc_error ("The parameter expression at %C does not "
+			 "simplify to an INTEGER constant");
+	      goto error_return;
+	    }

 	  tail->expr = gfc_copy_expr (kind_expr);
 	}
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_23.f90 b/gcc/testsuite/gfortran.dg/dec_structure_23.f90
index 78db344e0fc..39e5369c056 100644
--- a/gcc/testsuite/gfortran.dg/dec_structure_23.f90
+++ b/gcc/testsuite/gfortran.dg/dec_structure_23.f90
@@ -13,8 +13,8 @@  program p
   integer :: nn
   real :: rr
   structure /s/
-    integer x(n)    /1/   ! { dg-error "array with nonconstant bounds" }
+    integer x(n)    /1/   ! { dg-error "must be constant of INTEGER type" }
     integer xx(nn)  /1/   ! { dg-error "array with nonconstant bounds" }
-    integer xxx(rr) /1.0/ ! { dg-error "array with nonconstant bounds" }
+    integer xxx(rr) /1.0/ ! { dg-error "must be constant of INTEGER type" }
   end structure
 end
diff --git a/gcc/testsuite/gfortran.dg/pr95053_2.f90 b/gcc/testsuite/gfortran.dg/pr95053_2.f90
new file mode 100644
index 00000000000..7bb941ab46e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95053_2.f90
@@ -0,0 +1,10 @@ 
+! { dg-do compile }
+! PR 95053 - make sure we do not regress on 521.wrf_r from spec2017
+!
+function f (x)
+  real, parameter :: cldeps = 0.
+  f = 0.
+  if (cldeps > 0.) then
+     f = floor (x/cldeps) * cldeps
+  end if
+end function f
diff --git a/gcc/testsuite/gfortran.dg/pr95053_3.f90 b/gcc/testsuite/gfortran.dg/pr95053_3.f90
new file mode 100644
index 00000000000..eae3d8fc41e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95053_3.f90
@@ -0,0 +1,14 @@ 
+! { dg-do compile }
+! Related to PR 93499 - this used to ICE.
+
+program p
+  type t(n)
+     integer, kind :: n
+  end type t
+  type u(n)
+     integer, len :: n
+  end type u
+  type(t((0)/0))  :: x  ! { dg-error "does not simplify to an INTEGER" }
+  type(t((0.)/0)) :: y  ! { dg-error "must be of INTEGER type" }
+  type(u(0/(0.))) :: z  ! { dg-error "must be of INTEGER type" }
+end