[PATCH] analyzer/pr94028.C and non-null warning

[David Malcolm]

On Tue, 2020-06-30 at 09:51 -0400, David Edelsohn wrote:
> The changes to the non-null warning now produce an additional warning
> for analyzer/pr94028.C on one of the "leak" lines.  This causes new
> failures on trunk.

Hi David

Do you have the output to hand?  What is the full text of the new
diagnostic?

Some high level questions:
  * Ought GCC to warn for that code?  (or not)
  * Is it behavior we ought to have a test for?

Note that AFAIK there are *two* kinds of non-null warnings that GCC can
emit: the kind emitted by Martin's code, versus those emitted by
-fanalyzer (the latter imply the much more expensive analysis performed
by -fanalyzer, and are controlled by the various -Wanalyzer-*null*
options; see 
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html
)


> Because non-null is not the purpose of the analyzer test, I propose
> pruning the output to resolve the new failures.

Looking back through bugzilla, it seems that the main purpose of adding
that test was to ensure that -fanalyzer doesn't ICE on that code.

At some point I hope to properly support C++ in -fanalyzer, at which
point some kind of null warning may be warranted on that code.  Sadly
I'm not yet at that point.  FWIW I'm currently working on a big rewrite
of how state is tracked within the analyzer, as I've identified at
least two major flaws in the current implementation, which my rewrite
addresses.  I'm deferring on C++ support until that rewrite is done.

>   Alternatively, I
> could explicitly test for the additional non-null warning.
> 
> Do you have any preferences?

This test is controlled by analyzer.exp and thus, for example, is
disabled if the analyzer was disabled at configure time.

If this is coming from Martin's non-analyzer code, a third possibility
would be to use -Wno-something to disable that warning, so that the
analyzer test can focus on the -fanalyzer test, as it were (and if this
is a behavior that ought to be checked for in Martin's warning, then
copy the pertinent fragment of the testcase to one of the g++.dg cases,
I suppose).  I think I prefer that approach.

How does this sound?

> I propose appending
> 
> // { dg-prune-output "where non-null expected" }
> 
> to the file to prune the warning output.
> 
> Thanks, David

Thanks for looking into this; hope this is constructive.
Dave