Re: [PATCH] Makefile: force -O0 when compiling with SANITIZE=leak

From: Jeff King <peff@peff.net>
Date: Oct 21, 2022, 06:04 UTC
Message-ID: <Y1I2Z9K4iaAr+GiP@coredump.intra.peff.net>
In-Reply-To: <939ccb0c-005c-4f98-a6ca-3f8e5cda1641@gmail.com>

On Thu, Oct 20, 2022 at 08:57:31PM +0200, Rubén Justo wrote:

> "-O2" is what goes public, testing it, directly or indirectly, is useful.
> Another thing is the pay-off..

Sort of. The leak-check build itself is not what goes public, so we have already diverged from a release build. But yes, if there were cases that -O2 caught that -O0 did not, that would be of interest.

But are there?

I.e., we already know of false positives with -O2. Are there false negatives with -O0?

The example you give below goes the other way:

Show 8 quoted lines

> "False positives" makes me think the leak checker does its best.  And the
> compiler.  This "-O0 leak" is ignored by both, with "-O2":
> 
> 	void func()
> 	{
> 		malloc(1024);
> 		exit(1);
> 	}

It is a false negative with -O2. Which again seems to argue for using -O0.

> UNLEAK(), "-O0" as a /second opinion/ /confirmation/, some attention to the
> false positives,... are things that doesn't sound so bad.  Maybe there is a
> better way.  Dunno.

I don't know why we'd want to prefer -O2 if we know it produces worse results, but don't have any cases where it produce better ones (or even a plausible explanation for why it might). Sure, we could squelch its false positives with UNLEAK(), but:

  - that's per-site work, versus setting -O0 once

  - UNLEAK() suppresses false positives, but it also would suppress true
    positives (e.g., if the code later changed and somebody introduced a
    leak). It seems better to avoid that if possible.

-Peff