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.
