https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138
--- Comment #8 from kargl at troutmask dot apl.washington.edu <kargl at
troutmask dot apl.washington.edu> ---
On Mon, Apr 02, 2018 at 05:50:30PM +0000, tkoenig at gcc dot gnu.org wrote:
>
> --- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
> First, I have renamed the function "len" to "llen" in the original
> test case to avoid confusion with the intrinsic.
>
> The problem seems to be that, at the entry of pure_function(),
> there are different opinions about purity:
>
> (gdb) p e->symtree->n.sym->name
> $6 = 0x7ffff743b078 "llen"
> (gdb) p e->symtree->n.sym->attr.pure
> $7 = 0
> (gdb) p e->value.function
> $8 = {actual = 0x2515700, name = 0x7ffff7438a80 "str_real_sp_fmt_len", isym =
> 0x0, esym = 0x2581200}
> (gdb) p e->value.function.esym->attr.pure
> $9 = 1
>
> (Why this problem is exposed by Steve's patch, I have no idea).
>
I don't have time to look, but if the gfc_reduce_init_expr() is
now being invoked from my patch I suspect that you either have
e->symtree->n.sym->attr.pure overwriting e->value.function.esym->attr.pure
or vice versa.
