https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
--- Comment #28 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #27)
> (In reply to Mikael Morin from comment #25)
> > (In reply to Mikael Morin from comment #24)
> > > (In reply to Mikael Morin from comment #23)
> > > >
> > > > This regresses on pr108065.f90 (that's a few extra analyzer warnings),
> > > > and on pr69955.f90 (that's one extra __builtin_malloc).
> > >
> > > This removes the regressions. Not fully retested again.
> > >
> > Comment #23 is probably the more correct one.
> > Comment #24 works because of the double temporary. Even if the first
> > temporary has NULL data component, the second one uses malloc
> > unconditionally to set data, and the argument is seen as present.
>
> Are you sure that you haven't mixed up those two?
>
> When trying with my extended testcase, and looking at the tree dump,
> I see a double temporary for the call
>
> call i ([real:: y])
>
> where the data pointer to the first allocation is clobbered later.
> So I would rather go with the version from comment #24.
>
Let's rephrase:
When (or rather if) we manage to remove the double temporary, we'll regress
with comment #24, not with comment #23.
The reallocation remains by the way, it's only pushed one step away.
Try this for example:
call i([real:: y, y])
> If you don't object, I'll package the patch with testcases and submit.
No problem, I think we are safe with the second temporary.
