https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69064
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #50 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #49)
> > Fairly trivial to fix once one finds
> >
> > F2003, p. 126.
> >
> > A variable in a specification expression shall have its type and
> > type parameters, if any, specified by a previous declaration in
> > the same scoping unit, by the implicit typing rules in effect for
> > the scoping unit, or by host or use association.
> >
> > Note, the fix requires adjusting 2 testcases for new error
> > conditions and fixing 1 testcase that actually has invalid
> > code.
>
> Thanks for the pointer. I am indeed aware that the original code and the
> reduced versions posted in comments 41 and 47 are invalid and easy to fix.
That's not what I was writing about. Once one understands F2003
and fixes gfortran, then the Note below applies. That is, you need
to fix
M testsuite/gfortran.dg/array_constructor_26.f03
M testsuite/gfortran.dg/array_constructor_27.f03
M testsuite/gfortran.dg/bounds_check_strlen_2.f90
> Nevertheless gfortran used to give an error up to revision r229286 and is
> now giving an ICE since revision r229287 for trunk (6.0) and r229553 for the
> 5 branch. The path to the original error should be restored.
That isn't the fix that is needed as the original path can't be restored.
