[fortran] PR114535 - [13/14 regression] ICE with elemental finalizer
Checks
Context |
Check |
Description |
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_check--master-arm |
success
|
Testing passed
|
Commit Message
Hi All,
This one is blazingly 'obvious'. I haven't had the heart to investigate why
somebody thought that it is a good idea to check if unreferenced symbols
are finalizable because, I suspect, that 'somebody' was me. Worse, I tried
a couple of other fixes before I hit on the 'obvious' one :-(
The ChangeLog says it all. OK for mainline and then backporting in a couple
of weeks?
Paul
Fortran: Fix ICE in trans-stmt.cc(gfc_trans_call) [PR114535]
2024-04-08 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/114535
* resolve.cc (resolve_symbol): Remove last chunk that checked
for finalization of unreferenced symbols.
gcc/testsuite/
PR fortran/114535
* gfortran.dg/pr114535d.f90: New test.
* gfortran.dg/pr114535iv.f90: Additional source.
Comments
On 4/8/24 2:45 AM, Paul Richard Thomas wrote:
> Hi All,
>
> This one is blazingly 'obvious'. I haven't had the heart to investigate why somebody thought that it is a good idea to check if unreferenced symbols are finalizable because, I suspect, that
> 'somebody' was me. Worse, I tried a couple of other fixes before I hit on the 'obvious' one :-(
>
> The ChangeLog says it all. OK for mainline and then backporting in a couple of weeks?
>
> Paul
>
> Fortran: Fix ICE in trans-stmt.cc(gfc_trans_call) [PR114535]
>
> 2024-04-08 Paul Thomas <pault@gcc.gnu.org <mailto:pault@gcc.gnu.org>>
>
> gcc/fortran
> PR fortran/114535
> * resolve.cc (resolve_symbol): Remove last chunk that checked
> for finalization of unreferenced symbols.
>
> gcc/testsuite/
> PR fortran/114535
> * gfortran.dg/pr114535d.f90: New test.
> * gfortran.dg/pr114535iv.f90: Additional source.
>
Yes, OK Paul. Don't feel bad. It wasn't Tabs. LOL
Jerry
@@ -17069,15 +17069,6 @@ resolve_symbol (gfc_symbol *sym)
if (sym->param_list)
resolve_pdt (sym);
-
- if (!sym->attr.referenced
- && (sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED))
- {
- gfc_expr *final_expr = gfc_lval_expr_from_sym (sym);
- if (gfc_is_finalizable (final_expr->ts.u.derived, NULL))
- gfc_set_sym_referenced (sym);
- gfc_free_expr (final_expr);
- }
}
new file mode 100644
@@ -0,0 +1,42 @@
+! { dg-do compile }
+! { dg-compile-aux-modules "pr114535iv.f90" }
+! Contributed by Andrew Benson <abensonca@gcc.gnu.org>
+!
+module d
+ implicit none
+contains
+ function en() result(dd)
+ use :: iv
+ implicit none
+ type(vs) :: dd
+ dd%i = 1
+ end function en
+end module d
+
+! Delete line 1 and all brands complain that 'vs' is an undefined type.
+! Delete lines 1 and line 2 recreates the original problem.
+module ni
+ implicit none
+contains
+ subroutine iss1()
+! use :: iv ! line 1
+ use :: d
+ implicit none
+! type(vs) :: ans; ans = en(); ! line 2
+ end subroutine iss1
+ subroutine iss2()
+ use :: d
+ implicit none
+ end subroutine iss2
+end module ni ! Used to give an ICE: in gfc_trans_call, at fortran/trans-stmt.cc:400
+
+ use ni
+ use iv
+ type(vs) :: x
+ call iss1()
+ call iss1()
+ if ((ctr .eq. 0) .or. (ctr .ne. 6)) stop 1 ! Depends whether lines 1 & 2 are present
+ call iss2()
+ x = vs(42)
+ if ((ctr .eq. 1) .or. (ctr .ne. 7)) stop 2 ! Make sure destructor available here
+end
new file mode 100644
@@ -0,0 +1,18 @@
+! Compiled with pr114535d.f90
+! Contributed by Andrew Benson <abensonca@gcc.gnu.org>
+!
+module iv
+ type, public :: vs
+ integer :: i
+ contains
+ final :: destructor
+ end type vs
+ integer :: ctr = 0
+contains
+ impure elemental subroutine destructor(s)
+ type(vs), intent(inout) :: s
+ s%i = 0
+ ctr = ctr + 1
+ end subroutine destructor
+end module iv
+