[Bug tree-optimization/62035] [4.9/4.10 Regression] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Marc, do you think it's possible to warn about such "return of local
> addresses"?

It doesn't seem easy. Here are some random thoughts.

At the exit of a block, we can say that the address of sv becomes nonsense, but
we don't have an easy way to replace it with 0 or undefined. The front end
doesn't track the leaking address. In the middle-end, we don't know anymore
that &sv is meaningless. AFAIK, in SSA, all variables live for the whole
function, the clobber only tells us that the content is nonsense, but the
address itself can perfectly well be reused to write new content. So we are
left with trying to warn about the read-after-clobber.

bb 10 ends with:
  # .MEM_37 = VDEF <.MEM_36>
  svD.22441 ={v} {CLOBBER};

bb 11 contains:
  # svp_2 = PHI <&svD.22441(10), svp_28(9)>
  # .MEM_3 = PHI <.MEM_37(10), .MEM_40(9)>
  if (_41 != 0)
    goto <bb 12>;

and bb 12 starts with:
  # VUSE <.MEM_3>
  _42 = *svp_2;

It is possible to see from this that _42 will receive garbage if we take the
path 10 -> 11 -> 12. But that's going to be an awfully specific piece of code
(and we don't want to start a walk of vdefs every time something is
dereferenced). I haven't yet studied the passes that track values in memory, so
I don't know if they can be adapted. I think there are lower hanging fruits
than this though.