[Bug c/105346] New: -Wno-free-nonheap-object false positive (on Bison-generated grammar code)

[Bug c/105346] New: -Wno-free-nonheap-object false positive (on Bison-generated grammar code)

[tim.vanholder at anubex dot com]

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

            Bug ID: 105346
           Summary: -Wno-free-nonheap-object false positive (on
                    Bison-generated grammar code)
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tim.vanholder at anubex dot com
  Target Milestone: ---

Bison grammars (can) include code like

    /* The state stack: array, bottom, top.  */
    yy_state_t yyssa[YYINITDEPTH];
    yy_state_t *yyss = yyssa;
    yy_state_t *yyssp = yyss;

... (code that may allocate a larger stack if needed, in which case `yyss` and
`yyssp` get repointed)


  #ifndef yyoverflow
    if (yyss != yyssa)
      YYSTACK_FREE (yyss);
  #endif

(with YYSTACK_FREE() expanding to free()).

For this gcc (Debian 11.2.0-19) 11.2.0 is reporting (with -Werror):

Linux/DML-grammar.cc:13901:18: error: ‘void free(void*)’ called on unallocated
object ‘yyssa’ [-Werror=free-nonheap-object]
13901 |     YYSTACK_FREE (yyss);
Linux/DML-grammar.cc:5609:16: note: declared here
 5609 |     yy_state_t yyssa[YYINITDEPTH];
      |                ^~~~~

So it is tracing yyss to yyssa from its declaration, but is apparently not
seeing that there is an explicit test that yyss is not equal to yyssa around
the free.

(I'd test with a more recent version, but this is what I have available.)

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-04-22

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It doesn't diagnose a simple testcase like

#include <stdlib.h>
void bar (void *);
void foo (int n)
{
  int a[100];
  int *p = a;
  if (n > 100)
    p = malloc (n*sizeof(int));
  bar (p);
  if (p != a)
    free (p);
}

so maybe you can provide preprocessed source of the TU that diagnoses such a
case in a more complicated setting?

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

[tim.vanholder at anubex dot com]

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

--- Comment #2 from Tim Van Holder <tim.vanholder at anubex dot com> ---
Sorry, missed that update. Will see what I can do.

It is a fairly large grammar; there are 8300 lines between the declaration and
the free(). Not sure if that is likely to matter.

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

[tim.vanholder at anubex dot com]

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

--- Comment #3 from Tim Van Holder <tim.vanholder at anubex dot com> ---
Created attachment 52880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52880&action=edit
testcase (redacted .ii file)

Right, I managed to strip out all code I'm not allowed to share.
I do seem to have messed up some of the location directives, so the warnings
claim it's part of included files when it's not.

This reproduces the warning, and even adds a second one of the exact same type
(which is NOT shown with the unredacted source).

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

[tim.vanholder at anubex dot com]

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

Tim Van Holder <tim.vanholder at anubex dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |c++

--- Comment #4 from Tim Van Holder <tim.vanholder at anubex dot com> ---
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).

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
           Keywords|                            |diagnostic

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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.

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

[rguenth at gcc dot 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.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |11.4
      Known to work|                            |10.3.1
            Summary|-Wno-free-nonheap-object    |[11/12 Regression]
                   |false positive (on          |-Wno-free-nonheap-object
                   |Bison-generated grammar     |false positive (on
                   |code)                       |Bison-generated grammar
                   |                            |code)

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
The diagnostic is new and enabled by default, so it's a regression.

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-5732-gdce6c58db87ebf7f4477bd3126228e73e4eeee97
The IL at -O0 -Wall looks during waccess pass like:
void foo ()
{
  char * bufp;
  char buf[20];

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

  <bb 3> :
  __builtin_free (bufp_2);

  <bb 4> :
  buf ={v} {CLOBBER(eol)};
  return;

}

So, I think the waccess pass must be walking SSA_NAME_DEF_STMT to figure out it
is a free of non-heap.  Either it shouldn't do that at -O0, or it should only
walk them when they are in the same bb as the free call, or it needs to be able
to detect also conditionals like the above.

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

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 26 Apr 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346
> 
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Started with r11-5732-gdce6c58db87ebf7f4477bd3126228e73e4eeee97
> The IL at -O0 -Wall looks during waccess pass like:
> void foo ()
> {
>   char * bufp;
>   char buf[20];
> 
>   <bb 2> :
>   bufp_2 = &buf;
>   if (&buf != bufp_2)
>     goto <bb 3>; [INV]
>   else
>     goto <bb 4>; [INV]
> 
>   <bb 3> :
>   __builtin_free (bufp_2);
> 
>   <bb 4> :
>   buf ={v} {CLOBBER(eol)};
>   return;
> 
> }
> 
> So, I think the waccess pass must be walking SSA_NAME_DEF_STMT to figure out it
> is a free of non-heap.  Either it shouldn't do that at -O0, or it should only
> walk them when they are in the same bb as the free call, or it needs to be able
> to detect also conditionals like the above.

It's using the ptr-query framework which discovers the bufp_2 equivalence
but doesn't notice the conditional "invalidating" it.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #9)
> It's using the ptr-query framework which discovers the bufp_2 equivalence
> but doesn't notice the conditional "invalidating" it.

Then what I wrote above should apply to the pointer-query.cc code if !optimize.

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

[amacleod at redhat dot com]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #6)

> 
>   <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 relation oracle currently only works with ssa-names.
- Ranger also doesn't currently track that sort of symbolic equivalence with
irange.
- the VRP passes have a pointer tracking mechanism as part of the dom walk, and
the call to rvrp_folder::value_of_expr (bufp_2) would give us &buf.  I also
think we also would fold the stmt in VRP.  This could in theory be extended to
any pass doing a dom walk.  however:
- I believe the upcoming prange extension for pointer ranges in stage 1 will
make this happen naturally with rangers query system. range_of_stmt ( if <..>)
would then produce bool [0, 0].  I would also expect that prange will have an
easy way to ask what its base/equivalence(s) are.

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

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #11)

> - The relation oracle currently only works with ssa-names.
> - Ranger also doesn't currently track that sort of symbolic equivalence with
> irange.
> - the VRP passes have a pointer tracking mechanism as part of the dom walk,
> and the call to rvrp_folder::value_of_expr (bufp_2) would give us &buf.  I
> also think we also would fold the stmt in VRP.  This could in theory be
> extended to any pass doing a dom walk.  however:
> - I believe the upcoming prange extension for pointer ranges in stage 1 will
> make this happen naturally with rangers query system. range_of_stmt ( if
> <..>) would then produce bool [0, 0].  I would also expect that prange will
> have an easy way to ask what its base/equivalence(s) are.

Yeah, ranger itself doesn't deal with MEM_REF's and the like.  We work around
this in evrp by using the pointer_equiv_analyzer class which tracks pointer
equality in a DOM walk.  But this is only used by the evrp pass (not the
threader or any other ranger client).

prange should indeed take care of this.  It tracks pointer equality,
POINTER_PLUS_EXPR, POINTER_DIFF_EXPR, etc.  As you say, range_of_stmt should be
able to trivially fold the conditional.

For that matter, the pointer query code could probably all be replaced with
prange, instead of the ad-hoc pointer tracking it does.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #11)
> (In reply to Richard Biener from comment #6)
> 
> > 
> >   <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 relation oracle currently only works with ssa-names.
> - Ranger also doesn't currently track that sort of symbolic equivalence with
> irange.
> - the VRP passes have a pointer tracking mechanism as part of the dom walk,
> and the call to rvrp_folder::value_of_expr (bufp_2) would give us &buf.  I
> also think we also would fold the stmt in VRP.  This could in theory be
> extended to any pass doing a dom walk.  however:
> - I believe the upcoming prange extension for pointer ranges in stage 1 will
> make this happen naturally with rangers query system. range_of_stmt ( if
> <..>) would then produce bool [0, 0].  I would also expect that prange will
> have an easy way to ask what its base/equivalence(s) are.

OK, I was hoping I can so sth like

 range_simplify_expr (NE_EXPR, bufp_2, &buf, at_free_stmt);

and then by means of the dominating if condition get a 'true'.  Note the
diagnostic pass is not within a DOM walk so all I can use is an ad-hoc
query.  I'm not looking to simplify the conditional itself as that won't
help me with the current pass structure.

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

[aldyh at gcc dot gnu.org]

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

--- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> (In reply to Andrew Macleod from comment #11)
> > (In reply to Richard Biener from comment #6)
> > 
> > > 
> > >   <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 relation oracle currently only works with ssa-names.
> > - Ranger also doesn't currently track that sort of symbolic equivalence with
> > irange.
> > - the VRP passes have a pointer tracking mechanism as part of the dom walk,
> > and the call to rvrp_folder::value_of_expr (bufp_2) would give us &buf.  I
> > also think we also would fold the stmt in VRP.  This could in theory be
> > extended to any pass doing a dom walk.  however:
> > - I believe the upcoming prange extension for pointer ranges in stage 1 will
> > make this happen naturally with rangers query system. range_of_stmt ( if
> > <..>) would then produce bool [0, 0].  I would also expect that prange will
> > have an easy way to ask what its base/equivalence(s) are.
> 
> OK, I was hoping I can so sth like
> 
>  range_simplify_expr (NE_EXPR, bufp_2, &buf, at_free_stmt);
> 
> and then by means of the dominating if condition get a 'true'.  Note the
> diagnostic pass is not within a DOM walk so all I can use is an ad-hoc
> query.  I'm not looking to simplify the conditional itself as that won't
> help me with the current pass structure.

Hmmm, I suppose we could track inequality as well as equality in prange.  In
which case, we'd have:

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

bufp_2 : [prange] char[20] * [1B, +INF] [PT &buf]
2->3  (T) bufp_2 :      [prange] char[20] * [1B, +INF] [PT !&buf]
2->4  (F) bufp_2 :      [prange] char[20] * [1B, +INF] [PT &buf]

=========== BB 3 ============
bufp_2  [prange] char[20] * [1B, +INF] [PT !&buf]
    <bb 3> :
    free (bufp_2);

Notice that the range of bufp_2 at free() is:

   bufp_2  [prange] char[20] * [1B, +INF] [PT !&buf]

Whereas range_of_expr of &buf (anywhere) would be:

   [prange] char[20] * [1B, +INF] [PT &buf]

The intersection of both is the empty set / UNDEFINED, and should be able to
get that without dominance info.

Would that help?

Right now we're tracking equality, but it should be trivial to track
non-equality by adjusting the op1_range range-op entries.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #14)
> (In reply to Richard Biener from comment #13)
> > (In reply to Andrew Macleod from comment #11)
> > > (In reply to Richard Biener from comment #6)
> > > 
> > > > 
> > > >   <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 relation oracle currently only works with ssa-names.
> > > - Ranger also doesn't currently track that sort of symbolic equivalence with
> > > irange.
> > > - the VRP passes have a pointer tracking mechanism as part of the dom walk,
> > > and the call to rvrp_folder::value_of_expr (bufp_2) would give us &buf.  I
> > > also think we also would fold the stmt in VRP.  This could in theory be
> > > extended to any pass doing a dom walk.  however:
> > > - I believe the upcoming prange extension for pointer ranges in stage 1 will
> > > make this happen naturally with rangers query system. range_of_stmt ( if
> > > <..>) would then produce bool [0, 0].  I would also expect that prange will
> > > have an easy way to ask what its base/equivalence(s) are.
> > 
> > OK, I was hoping I can so sth like
> > 
> >  range_simplify_expr (NE_EXPR, bufp_2, &buf, at_free_stmt);
> > 
> > and then by means of the dominating if condition get a 'true'.  Note the
> > diagnostic pass is not within a DOM walk so all I can use is an ad-hoc
> > query.  I'm not looking to simplify the conditional itself as that won't
> > help me with the current pass structure.
> 
> Hmmm, I suppose we could track inequality as well as equality in prange.  In
> which case, we'd have:
> 
> =========== BB 2 ============
> Imports: bufp_2
> Exports: bufp_2
>     <bb 2> :
>     bufp_2 = &buf;
>     if (&buf != bufp_2)
>       goto <bb 3>; [INV]
>     else
>       goto <bb 4>; [INV]
> 
> bufp_2 : [prange] char[20] * [1B, +INF] [PT &buf]
> 2->3  (T) bufp_2 :      [prange] char[20] * [1B, +INF] [PT !&buf]
> 2->4  (F) bufp_2 :      [prange] char[20] * [1B, +INF] [PT &buf]
> 
> =========== BB 3 ============
> bufp_2  [prange] char[20] * [1B, +INF] [PT !&buf]
>     <bb 3> :
>     free (bufp_2);
> 
> Notice that the range of bufp_2 at free() is:
> 
>    bufp_2  [prange] char[20] * [1B, +INF] [PT !&buf]
> 
> Whereas range_of_expr of &buf (anywhere) would be:
> 
>    [prange] char[20] * [1B, +INF] [PT &buf]
> 
> The intersection of both is the empty set / UNDEFINED, and should be able to
> get that without dominance info.
> 
> Would that help?
> 
> Right now we're tracking equality, but it should be trivial to track
> non-equality by adjusting the op1_range range-op entries.

If it isn't possible to use ranger at the moment to resolve this at
the point of the free() call I wouldn't bother.  I think the correct
solution is indeed to see the code is unreachable even at -O0
(similar as to what we now to for uninit analysis - run VN in
analysis mode).  I hope somebody will have the time to refactor all
the various diagnostic passes to run from a single driver / CFG walk
making it possible to do this.

Alternatively use some function-local -Wanalyzer for the new fancy
diagnostics or at least share code with it.

If we think this case is important to fix I'd resort to pattern matching
the conditional.

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

[aldyh at gcc dot gnu.org]

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

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)

> If it isn't possible to use ranger at the moment to resolve this at
> the point of the free() call I wouldn't bother.  I think the correct

Ranger at the moment doesn't have prange.  This is for GCC 13.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
A possible fix would be to not run the late checks when not optimizing - in
fact
the IL for the late and early pass are the same at -O0 so the reason for
postponing them isn't there.  The only difference is inlining of always-inline
functions where one could argue we should do most -O0 diagnostics at that
state anyway.

Like with the following.  Alternatively at -O0 the very first pass instance
could do all checking but within a similar construct as the immediately
preceeding early -Wuninitialized.

diff --git a/gcc/passes.def b/gcc/passes.def
index 375d3d62d51..0442b85ee1b 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -402,6 +402,7 @@ along with GCC; see the file COPYING3.  If not see
          number of false positives from it.  */
       NEXT_PASS (pass_split_crit_edges);
       NEXT_PASS (pass_late_warn_uninitialized);
+      NEXT_PASS (pass_warn_access, /*early=*/false);
       /* uncprop replaces constants by SSA names.  This makes analysis harder
         and thus it should be run last.  */
       NEXT_PASS (pass_uncprop);
@@ -428,7 +429,6 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_gimple_isel);
   NEXT_PASS (pass_harden_conditional_branches);
   NEXT_PASS (pass_harden_compares);
-  NEXT_PASS (pass_warn_access, /*early=*/false);
   NEXT_PASS (pass_cleanup_cfg_post_optimizing);
   NEXT_PASS (pass_warn_function_noreturn);

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.