https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
> (In reply to Dominique d'Humieres from comment #2)
> > Up to revision r258235 (2018-03-04) compiling the test gave the error
> >
> > if (.not.checkFmt(fmt)) then
> > 1
> > Error: Reference to impure function 'checkfmt' at (1) within a PURE
> > procedure
> >
> > After revision r258362 (2018-03-08) I get the ICE. This has been back ported
> > to 7.3.1.
> >
> > In this range I see only r258281, r258305, and r258347, but r258305 has not
> > been back ported.
>
> Bizarrely it is r258347 that is the trigger. It has been backported without
> any ill effects.
>
It's probably not bizarre when a user does something like overloading
the name of an intrinsic subprogram and then tries to use it in a
specification statement. Something that the contributor of r258347
and of very little brain would never do. The simple fix is to not
be too clever.
interface length
module procedure alen, blen ! renamed to shorter symbols for debugging
end interface
function str_real_dp_matrix(xa) result(s)
real, intent(in) :: xa
character(len=length(xa)) :: s
end function str_real_dp_matrix
% gfc -c a.f90
a.f90:12:18:
if (.not.checkFmt(fmt)) then
1
Error: Reference to impure function 'checkfmt' at (1) within a PURE procedure
If I had to guess the gfc_reduce_init_expr() in r258347 is
disabling the reporting of errors at some point when
len=len(xa) is being reduced.
