fortran: Fix error recovery on invalid inquiry refs [PR127683]
Commit Message
Dear all,
the attached obvious patch fixes an ICE (assert) on invalid code that
was introduced in 14-development during the work on ASSOCIATE issues.
Regtested on x86_64-pc-linux-gnu. OK for mainline / backports?
Thanks,
Harald
Comments
On 10/2/26 14:52, Harald Anlauf wrote:
> Dear all,
>
> the attached obvious patch fixes an ICE (assert) on invalid code that
> was introduced in 14-development during the work on ASSOCIATE issues.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline / backports?
Yes for both mainline and back porting.
The memleak fixes verge of the "obviously correct" criteria.
Am 03.10.26 um 12:06 AM schrieb Steve Kargl:
> On 10/2/26 14:52, Harald Anlauf wrote:
>> Dear all,
>>
>> the attached obvious patch fixes an ICE (assert) on invalid code that
>> was introduced in 14-development during the work on ASSOCIATE issues.
>>
>> Regtested on x86_64-pc-linux-gnu. OK for mainline / backports?
>
> Yes for both mainline and back porting.
> The memleak fixes verge of the "obviously correct" criteria.
Thanks, Steve!
Pushed r17-4855-gab3c778a2530b2 so far.
Harald
From 84a3a8e4e17babdaab29860e83f4c955f89ca9de Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Fri, 2 Oct 2026 23:37:46 +0200
Subject: [PATCH] fortran: Fix error recovery on invalid inquiry refs
[PR127683]
Commit r14-9489 added an assert that could trigger while parsing an inquiry
ref. Replace assertion by the return of a failure value. Fix latent
frontend memleaks on error return path.
PR fortran/127683
gcc/fortran/ChangeLog:
* primary.cc (gfc_match_varspec): Fix two minor frontend memleaks.
* symbol.cc (gfc_find_derived_types): Return 0 when sym->assoc is
NULL.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr127683.f90: New test.
---
gcc/fortran/primary.cc | 2 ++
gcc/fortran/symbol.cc | 3 ++-
gcc/testsuite/gfortran.dg/pr127683.f90 | 10 ++++++++++
3 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr127683.f90
@@ -2651,6 +2651,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
{
gfc_error ("The RE or IM part_ref at %C must be "
"applied to a COMPLEX expression");
+ gfc_free_ref_list (tmp);
return MATCH_ERROR;
}
else if (tmp->u.i == INQUIRY_LEN
@@ -2658,6 +2659,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool sub_flag,
{
gfc_error ("The LEN part_ref at %C must be applied "
"to a CHARACTER expression");
+ gfc_free_ref_list (tmp);
return MATCH_ERROR;
}
}
@@ -2525,7 +2525,8 @@ gfc_find_derived_types (gfc_symbol *sym, gfc_namespace *ns,
const char *name, bool stash)
{
gfc_namespace *encompassing = NULL;
- gcc_assert (sym->assoc);
+ if (sym->assoc == NULL)
+ return 0;
cts = 0;
while (ns->parent)
new file mode 100644
@@ -0,0 +1,10 @@
+! { dg-do compile }
+!
+! PR fortran/127683 - we used to ICE on invalid inquiry refs
+
+program test
+ implicit none
+ print *, z%re ! { dg-error "must be applied to a COMPLEX expression" }
+ print *, c%len ! { dg-error "must be applied to a CHARACTER expression" }
+! print *, x%kind ! this also used to ICE, now gives a fatal error
+end program
--
2.51.0