[Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095

2023-10-29 Thread Paul Richard Thomas
Bizarrely, since the fix for pr101625, the testcase compiles and runs
correctly with s/select type (y => x)/select type (y => (x))/ !

The fix is straightforward and appears to be one of those wrinkles arising
from the use of associate variables as a selector. The fault is reasonable
since the expression is a reference to the _data field, which is of derived
type. However, being a select type selector, the selector must be a
class with that declared type.

Regtests fine. OK for mainline?

Paul

Fortran: Fix a problem with SELECT TYPE selectors [PR104555].

2023-10-29  Paul Thomas  

gcc/fortran
PR fortran/104555
* resolve.cc (resolve_select_type): If the selector expression
has no class component references and the expression is a
derived type, copy the typespec of the symbol to that of the
expression.

gcc/testsuite/
PR fortran/104555
* gfortran.dg/pr104555.f90: New test.
! { dg-do compile }
!
! Test the fix for PR104555 in which the select type statement caused an
! ICE because the selector expression was type(t) rather than class(t).
!
! Contributed by Gerhard Steinmetz  
!
program p
   type t
  character(:), allocatable :: a
   end type
   call s(t("abcd"))
   call s([t("efgh")])
contains
   subroutine s(x)
  class(t) :: x(..)
  select rank (x)
  rank (0)
 print *, "|", x%a, "|"
 select type (y => x)
 type is (t)
   print *, "|", y%a, "|"
 end select
  rank (1)
 print *, "|", x(1)%a, "|"
 select type (y => x)
 type is (t)
   print *, "|", y(1)%a, "|"
 end select
  end select
   end
end
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 9f4dc072645..b394f7fc79c 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9578,6 +9578,12 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
 	{
 	  if (code->expr1->symtree->n.sym->attr.untyped)
 	code->expr1->symtree->n.sym->ts = code->expr2->ts;
+	  /* Sometimes the selector expression is given the typespec of the
+	 '_data' field, which is logical enough but inappropraite here. */
+	  if (code->expr2->ts.type == BT_DERIVED
+	  && code->expr2->symtree
+	  && code->expr2->symtree->n.sym->ts.type == BT_CLASS)
+	code->expr2->ts = code->expr2->symtree->n.sym->ts;
 	  selector_type = CLASS_DATA (code->expr2)
 	? CLASS_DATA (code->expr2)->ts.u.derived : code->expr2->ts.u.derived;
 	}


Re: [Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095

2023-10-29 Thread Harald Anlauf

Hi Paul,

code->expr1->symtree->n.sym->ts = code->expr2->ts;
+ /* Sometimes the selector expression is given the typespec of the
+'_data' field, which is logical enough but inappropraite here. */

s/inappropraite/inappropriate/

+ if (code->expr2->ts.type == BT_DERIVED


otherwise it LGTM.

Thanks for the patch!

Harald

On 10/29/23 13:29, Paul Richard Thomas wrote:

Bizarrely, since the fix for pr101625, the testcase compiles and runs
correctly with s/select type (y => x)/select type (y => (x))/ !

The fix is straightforward and appears to be one of those wrinkles arising
from the use of associate variables as a selector. The fault is reasonable
since the expression is a reference to the _data field, which is of derived
type. However, being a select type selector, the selector must be a
class with that declared type.

Regtests fine. OK for mainline?

Paul

Fortran: Fix a problem with SELECT TYPE selectors [PR104555].

2023-10-29  Paul Thomas  

gcc/fortran
PR fortran/104555
* resolve.cc (resolve_select_type): If the selector expression
has no class component references and the expression is a
derived type, copy the typespec of the symbol to that of the
expression.

gcc/testsuite/
PR fortran/104555
* gfortran.dg/pr104555.f90: New test.