https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
--- Comment #29 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #28) > (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]) I do see the reallocation, but in the case of the patch in #24 it is a realloc of a NULL, which is well-defined nowadays. But I do not see a regression. On the contrary, every else seems unchanged. > > > 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. Besides the issue with one or two temporaries, is there anything else?
