[PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Harald Anlauf]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Dear Fortranners,

we missed certain intrinsics as being disallowed in constant expressions,
which lead to an ICE when these intrinsics were used in a specification
expression with an initializer.  The intrinsics in question are listed in
F2018:10.1.2.

As discussed in the PR, Steve recommended to omit TRANSFER from that list,
as it is special and might need separate treatment.  I also could not come
up with a case where TRANSFER should not have simplified to a constant and
we would run into an issue.  (We could leave that job to Gerhard... ;-).

However, in testing I encountered a case involving TRANSFER that is not
properly simplified, which seems orthogonal to the present case.  I would
like to handle this separately.  This case is mentioned in the testcase,
but commented out.

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

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr102458.diff --]
[-- Type: text/x-patch, Size: 3115 bytes --]

Fortran - improve checking for intrinsics allowed in constant expressions

gcc/fortran/ChangeLog:

	PR fortran/102458
	* expr.c (is_non_constant_intrinsic): Check for intrinsics
	excluded in constant expressions (F2018:10.1.2).
	(gfc_is_constant_expr): Use that check.

gcc/testsuite/ChangeLog:

	PR fortran/102458
	* gfortran.dg/pr102458.f90: New test.

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 604e63e6164..5ad1c4f9523 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -990,6 +990,34 @@ done:
 }


+/* Standard intrinsics listed under F2018:10.1.2 (6), which are excluded in
+   constant expressions, except TRANSFER (c.f. item (8)), which would need
+   separate treatment.  */
+
+static bool
+is_non_constant_intrinsic (gfc_expr *e)
+{
+  if (e->expr_type == EXPR_FUNCTION
+      && e->value.function.isym)
+    {
+      switch (e->value.function.isym->id)
+	{
+	  case GFC_ISYM_COMMAND_ARGUMENT_COUNT:
+	  case GFC_ISYM_GET_TEAM:
+	  case GFC_ISYM_NULL:
+	  case GFC_ISYM_NUM_IMAGES:
+	  case GFC_ISYM_TEAM_NUMBER:
+	  case GFC_ISYM_THIS_IMAGE:
+	    return true;
+
+	default:
+	  return false;
+	}
+    }
+  return false;
+}
+
+
 /* Determine if an expression is constant in the sense of F08:7.1.12.
  * This function expects that the expression has already been simplified.  */

@@ -1023,6 +1051,10 @@ gfc_is_constant_expr (gfc_expr *e)
       gcc_assert (e->symtree || e->value.function.esym
 		  || e->value.function.isym);

+      /* Check for intrinsics excluded in constant expressions.  */
+      if (e->value.function.isym && is_non_constant_intrinsic (e))
+	return false;
+
       /* Call to intrinsic with at least one argument.  */
       if (e->value.function.isym && e->value.function.actual)
 	{
diff --git a/gcc/testsuite/gfortran.dg/pr102458.f90 b/gcc/testsuite/gfortran.dg/pr102458.f90
new file mode 100644
index 00000000000..555e4978fdb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102458.f90
@@ -0,0 +1,42 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/102458 - standard intrinsics excluded in constant expressions
+
+subroutine s1
+  integer :: a(command_argument_count()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+program p
+  block
+    integer :: a(get_team()) = 1 ! { dg-error "Automatic array" }
+    print *, a
+  end block
+end
+
+subroutine s2
+  integer :: a(num_images()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+function f()
+  block
+    integer :: a(team_number()) = 0 ! { dg-error "Automatic array" }
+    a = 1
+  end block
+end
+
+subroutine s3
+  integer :: a(this_image()) = 1 ! { dg-error "Automatic array" }
+  print *, a
+end
+
+subroutine s4
+  integer, parameter :: n = 4
+  integer, parameter :: x(transfer(n, n)) = 1 ! legal
+  integer            :: y(transfer(n, n)) = 2 ! legal
+  integer, parameter :: k = size (x)          ! ok
+! integer, parameter :: m = size (y)          ! fails, tracked separately
+  print *, k, x, y
+  if (k /= size (y)) stop 1
+end

Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Jerry D]

Harald,

Looks good. OK and thanks for your time and efforts.

Jerry

On 9/23/21 12:47 PM, Harald Anlauf via Fortran wrote:
> Dear Fortranners,
>
> we missed certain intrinsics as being disallowed in constant expressions,
> which lead to an ICE when these intrinsics were used in a specification
> expression with an initializer.  The intrinsics in question are listed in
> F2018:10.1.2.
>
> As discussed in the PR, Steve recommended to omit TRANSFER from that list,
> as it is special and might need separate treatment.  I also could not come
> up with a case where TRANSFER should not have simplified to a constant and
> we would run into an issue.  (We could leave that job to Gerhard... ;-).
>
> However, in testing I encountered a case involving TRANSFER that is not
> properly simplified, which seems orthogonal to the present case.  I would
> like to handle this separately.  This case is mentioned in the testcase,
> but commented out.
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> Thanks,
> Harald
>

Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Thomas Koenig]

On 23.09.21 21:47, Harald Anlauf via Fortran wrote:
> Dear Fortranners,
> 
> we missed certain intrinsics as being disallowed in constant expressions,
> which lead to an ICE when these intrinsics were used in a specification
> expression with an initializer.  The intrinsics in question are listed in
> F2018:10.1.2.
> 
> As discussed in the PR, Steve recommended to omit TRANSFER from that list,
> as it is special and might need separate treatment.  I also could not come
> up with a case where TRANSFER should not have simplified to a constant and
> we would run into an issue.  (We could leave that job to Gerhard... ;-).
> 
> However, in testing I encountered a case involving TRANSFER that is not
> properly simplified, which seems orthogonal to the present case.  I would
> like to handle this separately.  This case is mentioned in the testcase,
> but commented out.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?

It was actually 10.1.12 :-)

OK for trunk.

Thanks for the patch!

Best regards

	Thomas

Aw: Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

[Harald Anlauf]

Hi Thomas,

> > Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> It was actually 10.1.12 :-)

dang, you're right.  Steve had it right, and I failed miserably
on copy&paste.  I should fix the comment.

> OK for trunk.
>
> Thanks for the patch!

Thanks for the review, which came after Jerry's!
I should have waited for yours, too.

Harald

> Best regards
>
> 	Thomas