[PATCH] PR fortran/103505 - ICE in compare_bound_mpz_t, at fortran/resolve.c:4587

2021-12-02 Thread Harald Anlauf via Fortran
Dear Fortranners,

specifying invalid constant array declarations (e.g. real array bounds)
could lead to an ICE because the array specs were checked for consistency.
A possible solution is to try an early simplification before doing that
check and was suggested by Steve.

However, regtesting did reveal that bad declarations involving e.g.
arithmetic errors - like division by zero - were now handled differently.
(The relevant testcase was gfortran.dg/arith_divide_2.f90).

I therefore added a new function gfc_try_simplify_expr that accepts the
simplification only if no error occurs.  This allows discovery of
arithmetic errors also at later stages and will be used here.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From 27f981bd1e9611373e4565c1d350b1da3eb653f0 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 2 Dec 2021 22:33:49 +0100
Subject: [PATCH] Fortran: improve checking of array specifications

gcc/fortran/ChangeLog:

	PR fortran/103505
	* array.c (match_array_element_spec): Try to simplify array
	element specifications to improve early checking.
	* expr.c (gfc_try_simplify_expr): New.  Try simplification of an
	expression via gfc_simplify_expr.  When an error occurs, roll
	back.
	* gfortran.h (gfc_try_simplify_expr): Declare it.

gcc/testsuite/ChangeLog:

	PR fortran/103505
	* gfortran.dg/pr103505.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/array.c|  4 
 gcc/fortran/expr.c | 25 +
 gcc/fortran/gfortran.h |  1 +
 gcc/testsuite/gfortran.dg/pr103505.f90 |  9 +
 4 files changed, 39 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103505.f90

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index fbc66097c80..5762c8d92d4 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -492,6 +492,8 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;

+  gfc_try_simplify_expr (*upper, 0);
+
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
   ((*upper)->expr_type == EXPR_FUNCTION
@@ -524,6 +526,8 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;

+  gfc_try_simplify_expr (*upper, 0);
+
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
   ((*upper)->expr_type == EXPR_FUNCTION
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 4084d18f136..87089321a3b 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2331,6 +2331,31 @@ gfc_simplify_expr (gfc_expr *p, int type)
 }


+/* Try simplification of an expression via gfc_simplify_expr.
+   When an error occurs (arithmetic or otherwise), roll back.  */
+
+bool
+gfc_try_simplify_expr (gfc_expr *e, int type)
+{
+  gfc_expr *n;
+  bool t, saved_div0;
+
+  if (e == NULL || e->expr_type == EXPR_CONSTANT)
+return true;
+
+  saved_div0 = gfc_seen_div0;
+  gfc_seen_div0 = false;
+  n = gfc_copy_expr (e);
+  t = gfc_simplify_expr (n, type) && !gfc_seen_div0;
+  if (t)
+gfc_replace_expr (e, n);
+  else
+gfc_free_expr (n);
+  gfc_seen_div0 = saved_div0;
+  return t;
+}
+
+
 /* Returns the type of an expression with the exception that iterator
variables are automatically integers no matter what else they may
be declared as.  */
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 1846ee4fd3c..24ad3ed4d06 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3585,6 +3585,7 @@ void gfc_free_ref_list (gfc_ref *);
 void gfc_type_convert_binary (gfc_expr *, int);
 bool gfc_is_constant_expr (gfc_expr *);
 bool gfc_simplify_expr (gfc_expr *, int);
+bool gfc_try_simplify_expr (gfc_expr *, int);
 int gfc_has_vector_index (gfc_expr *);

 gfc_expr *gfc_get_expr (void);
diff --git a/gcc/testsuite/gfortran.dg/pr103505.f90 b/gcc/testsuite/gfortran.dg/pr103505.f90
new file mode 100644
index 000..522e53efcb2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103505.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/103505 - this used to ICE in compare_bound_mpz_t
+! Testcase by G.Steinmetz
+
+program p
+  integer, parameter :: a((2.))   = [4,8] ! { dg-error "scalar INTEGER" }
+  integer, parameter :: z(1:(2.)) = [4,8] ! { dg-error "scalar INTEGER" }
+  print *, a(1:1) ! { dg-error "Syntax error" }
+end
--
2.26.2



Re: [power-ieee128] What should the math functions be annotated with?

2021-12-02 Thread Thomas Koenig via Fortran



On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:


Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
 && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define MATHFUNC(funcname) __ ## funcname ## ieee128
(i.e. use the functions that will be used when one uses e.g.
sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
if those need to be declared by libgfortran or math.h declares them).
Otherwise (when libgfortran is compiled against glibc older than 2.32)
it should use
#define MATHFUNC(funcname) funcname ## q
i.e. use the libquadmath APIs).


The current Ubuntu does not have these functions:

ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | 
grep ieee128

ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$

Will they be supplied in the future, or with the advanced toolchain?

Regards

Thomas