https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #9)
> Steve,
>
> what do you think about the following patch? Not yet fully regtested.
> It should fix the issue much simpler by checking type compatibility:
>
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 6050359d521..f4052eb7042 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -5139,6 +5141,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
> *ts2)
> bool is_union1 = (ts1->type == BT_UNION);
> bool is_union2 = (ts2->type == BT_UNION);
>
> + if (ts2->type == BT_BOZ)
> + return (ts1->type == BT_INTEGER || ts1->type == BT_REAL);
> +
> if (is_class1
> && ts1->u.derived->components
> && ((ts1->u.derived->attr.is_class
>
> Do you have a testcase that exercises BT_INTEGER and BT_REAL here?
> I thought that one of the pathes that reaches gfc_boz2int and gfc_boz2real
> might need the above.
Well, a boz is typeless, so it cannot be compatible with any other type.
So, I would assume, you could do
if (ts1->type == BT_BOZ || ts2->type == BT_BOZ)
return false;
There is a caveat in that Fortran 2023 is going to allow
things like
real :: x = z'1234'
if gfc_type_compatible is used in simple assignments, gfortran will
need to deal with that.
