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.