[Bug middle-end/105346] -Wno-free-nonheap-object false positive (on Bison-generated grammar code)

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com,
                   |                            |msebor at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
          Component|c++                         |middle-end

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Tim Van Holder from comment #4)
> > Marking as C++ rather than C; while Bison generates C code, here it gets
> > compiled in C++ context (with a namespace wrapped around Bison's symbols).
> 
> Thanks, I can confirm the diagnostic with -O0, it goes away when optimizing.
> 
> The issue seems to be that yyss (or yymsg) are not assigned to anywhere
> in the function and so we essentially have
> 
> void foo()
> {
>   char buf[20];
>   char *bufp = buf;
>   if (bufp != buf)
>     free (bufp);
> }
> 
> which we diagnose.  When optimizing the test is optimized away.

So - we have, at the waccess pass point an enabled ranger (but not done
any query yet).  The IL is

  <bb 2> :
  bufp_2 = &buf;
  if (&buf != bufp_2)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  __builtin_free (bufp_2);

and for the stmt __builtin_free (bufp_2) I'd like to ask if we know
that bufp_2 is != &buf (I'd expect a 'true' answer).  I think the
relation oracle should be able to answer this but I can't find the
appropriate API to use for this?

The code is in pass_waccess::maybe_check_dealloc_call in
gimple-ssa-warn-access.cc.

I can of course simply try to pattern match a GIMPLE_COND in the immediate
dominator as last resort.

I'd also notice that on the early pass we disable these kind of diagnostics
but the late is actually "earlier IL" at -O0 so I wonder if we want to
treat the last pass as early at -O0.