https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124598
Steve Kargl <kargl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
Known to fail| |14.3.1, 15.2.1, 16.0
Status|WAITING |NEW
--- Comment #5 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to Antoine Lemoine from comment #4)
> (In reply to Steve Kargl from comment #2)
> > (In reply to anlauf from comment #1)
> >
> > [...]
> >
> > 'n' is a type-param-name in 'type(t_baz(n)) :: baz'. OP's code is likely
> > invalid because 'n' does not appear in an specification expression.
> >
> > However, if one changes the code to
> >
> > type(t_baz) :: baz ! <- REMOVE THIS LINE AND THIS PROGRAM COMPILES
> >
> > or
> >
> > type(t_baz(n=10)) :: baz ! <- REMOVE THIS LINE AND THIS PROGRAM COMPILES
> >
>
> This mistake occurred when I created the minimal example. In the actual code
> where the ICE happened, n was assigned a value such as type(t_baz(3)). So,
> what I intended to do is valid.
Thanks for the confirmation. I assumed that there was an issue with cutting
a large code down to a minimum example. I have had similar issues in the
past.
Paul has put addressing the remaining PDT issues on hold until after the
upcoming GCC 16.1. He indicated in a post to the fortran@ list that he
needs to make some invasive changes to PDT internals, so he's reluctant
to make changes which may introduce regressions.
