[PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

[PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

[Harald Anlauf]

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

Dear Fortranners,

the recently introduced shape validation for array components
in DT constructors did not properly deal with invalid code
created by ingenious testers.

Obvious solution: replace the gcc_assert by a suitable error message.

Regarding the error message: before the shape validation, gfortran
would emit the same error message twice referring to the same line,
namely the bad declaration of the component.  With the attached patch
we get one error message for the bad declaration of the component,
and one for the structure constructor referring to that DT component.
One could easily change that and make the second message refer to the
same as the declaration, giving two errors for the same line.

Comments / opinions?

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

Thanks,
Harald


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

Fortran: error recovery on initializing invalid derived type array component

gcc/fortran/ChangeLog:

	PR fortran/102816
	* resolve.c (resolve_structure_cons): Reject invalid array spec of
	a DT component referred in a structure constructor.

gcc/testsuite/ChangeLog:

	PR fortran/102816
	* gfortran.dg/pr102816.f90: New test.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 5ccd9072c24..dc4ca5ef818 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1463,8 +1463,15 @@ resolve_structure_cons (gfc_expr *expr, int init)
 	  mpz_init (len);
 	  for (int n = 0; n < rank; n++)
 	    {
-	      gcc_assert (comp->as->upper[n]->expr_type == EXPR_CONSTANT
-			  && comp->as->lower[n]->expr_type == EXPR_CONSTANT);
+	      if (comp->as->upper[n]->expr_type != EXPR_CONSTANT
+		  || comp->as->lower[n]->expr_type != EXPR_CONSTANT)
+		{
+		  gfc_error ("Bad array spec of component %qs referred in "
+			     "structure constructor at %L",
+			     comp->name, &cons->expr->where);
+		  t = false;
+		  break;
+		};
 	      mpz_set_ui (len, 1);
 	      mpz_add (len, len, comp->as->upper[n]->value.integer);
 	      mpz_sub (len, len, comp->as->lower[n]->value.integer);
diff --git a/gcc/testsuite/gfortran.dg/pr102816.f90 b/gcc/testsuite/gfortran.dg/pr102816.f90
new file mode 100644
index 00000000000..46831743b2b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102816.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/102816
+
+program p
+  type t
+     integer :: a([2])     ! { dg-error "must be scalar" }
+  end type
+  type(t) :: x = t([3, 4]) ! { dg-error "Bad array spec of component" }
+end

Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

[Tobias Burnus]

Dear Harald, hi all,

On 22.10.21 21:36, Harald Anlauf via Fortran wrote:
> the recently introduced shape validation for array components
> in DT constructors did not properly deal with invalid code
> created by ingenious testers.
>
> Obvious solution: replace the gcc_assert by a suitable error message.
>
> Regarding the error message: before the shape validation, gfortran
> would emit the same error message twice referring to the same line,
> namely the bad declaration of the component.  With the attached patch
> we get one error message for the bad declaration of the component,
> and one for the structure constructor referring to that DT component.
> One could easily change that and make the second message refer to the
> same as the declaration, giving two errors for the same line.
>
> Comments / opinions?

Does not really matter in this case as long as there is one error for
the invalid "integer :: a([2])".

In other cases, it requires some careful weighting whether error should
have the error location "use m" or where the symbol is used. (Here, it
cannot occur as the module won't get generated and an error is already
printed at the proper location.)

> Regtested on x86_64-pc-linux-gnu.  OK?

OK.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467

[Harald Anlauf]

Hi Tobias,

> In other cases, it requires some careful weighting whether error should
> have the error location "use m" or where the symbol is used. (Here, it
> cannot occur as the module won't get generated and an error is already
> printed at the proper location.)

I had though about this but couldn't come up with a way to create
a module file from an invalid type definition.

The closest is sth. which imports it, such as in

program p
  type t
     integer :: a([2])     ! { dg-error "must be scalar" }
  end type
  type(t) :: x = t([3, 4]) ! { dg-error "Bad array spec of component" }
  interface
     subroutine foo (x)
       import t
       type(t) :: x
       type(t), parameter :: y = t([5, 6]) ! { dg-error "Bad array spec of component" }
     end subroutine foo
  end interface
end

However (= fortunately) this works just fine.

> > Regtested on x86_64-pc-linux-gnu.  OK?
> 
> OK.

Will commit tonight.  Thanks for the review!

Harald

> Tobias
> 
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
>