* [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
@ 2021-10-22 19:36 Harald Anlauf
2021-10-26 10:05 ` Tobias Burnus
0 siblings, 1 reply; 3+ messages in thread
From: Harald Anlauf @ 2021-10-22 19:36 UTC (permalink / raw)
To: fortran, gcc-patches
[-- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
2021-10-22 19:36 [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 Harald Anlauf
@ 2021-10-26 10:05 ` Tobias Burnus
2021-10-26 12:00 ` Harald Anlauf
0 siblings, 1 reply; 3+ messages in thread
From: Tobias Burnus @ 2021-10-26 10:05 UTC (permalink / raw)
To: Harald Anlauf, fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
2021-10-26 10:05 ` Tobias Burnus
@ 2021-10-26 12:00 ` Harald Anlauf
0 siblings, 0 replies; 3+ messages in thread
From: Harald Anlauf @ 2021-10-26 12:00 UTC (permalink / raw)
To: Tobias Burnus; +Cc: fortran, gcc-patches
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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-10-26 12:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-22 19:36 [PATCH] PR fortran/102816 - [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 Harald Anlauf
2021-10-26 10:05 ` Tobias Burnus
2021-10-26 12:00 ` Harald Anlauf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).