[Bug c++/98753] -Wfree-nonheap-object on Bison generated code

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

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can't reproduce the warning with the default options.  There are just two
calls to free() in the dump.  In each instance its argument resolves to the
yymsg pointer and not to the yyssa array as in the warning message in comment
#0.  We would also need to see the command line options you use to compile the
file (please review https://gcc.gnu.org/bugs/#need for the full details we ask
for).

In GCC 11, -Wfree-nonheap-object was enhanced to validate every argument to
every deallocation function.  Prior to GCC 11 it only considered a negligible
subset of arguments (basically just straight addresses of variables).  The
warning was prone to false positives then (as is evident from pr54202), and the
enhancement hasn't changed that.

Different optimization options produce different intermediate representation. 
Some result in constants substituted for what would otherwise be variables. 
When a constant is substituted into an expression that it's not valid for it
might trigger a warning because in the IL it's indistinguishable from a bug in
the original source code.  There's nothing a warning designed to detect such
invalid expressions can do about it.  Changing this message alone to say
"free() may be called with non-heap object" wouldn't be appropriate without
also changing all the other messages that are subject to the same problem (all
flow-sensitive warnings are).

At least two solutions are theoretically possible: a) make the warning
"smarter" than the optimization it depends on that does the substitution, and
have it figure out that the invalid code was synthesized by it, doesn't occur
in the source code, and cannot be reached in the program given the
preconditions, or b) make the optimizations "smarter" either by not
substituting constants into contexts where they're invalid, or by figuring out
that these invalid expressions cannot be reached based on their preconditions. 
The two sets of preconditions need not be the same.  Both approaches are worth
exploring but both are hard and neither will ever be perfect.  Which is partly
why GCC documents that "Warnings are diagnostic messages that report
constructions that are not inherently erroneous but that are risky or suggest
there may have been an error."  If the warning gets it wrong #pragma GCC
diagnostic can be used to avoid the false positive.