Re: Will -fsyntax-only hide issues with -pedantic? I think not...

From: Jeff King <peff@peff.net>
Date: Nov 30, 2021, 21:02 UTC
Message-ID: <YaaRaM8ApB36A9V2@coredump.intra.peff.net>
In-Reply-To: <211130.86ilw9epy3.gmgdl@evledraar.gmail.com>

On Tue, Nov 30, 2021 at 02:13:11PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 9 quoted lines

> The answer to $subject is not at all urgent, but I noticed we can get
> some (very modest) speed increases in the "pedantic" CI job when adding
> -fsyntax-only to CFLAGS. This currently requires monkeypatching out the
> "-o <target> -c" part hardcoded in the Makefile. See cebead1ebfb (ci:
> run a pedantic build as part of the GitHub workflow, 2021-08-08) for the
> pedantic job.
> 
> I.e. I'm aware of CFLAGS's -O<n> changing which warings we emit, but
> does -fsyntax-only?

I've never used -fsyntax-only. But I'd tend to doubt it, though, as I wouldn't expect -fsyntax-only to run through the optimizer. And indeed, the recent -O3 problem disappears there:

  $ gcc -fsyntax-only -I. -Wall -Werror -O3 refs.c
  [no output]

  $ gcc -o /dev/null -c -I. -Wall -Werror -O3 refs.c
  In file included from hashmap.h:4,
                   from cache.h:6,
                   from refs.c:5:
  In function ‘oidcpy’,
      inlined from ‘ref_transaction_add_update’ at refs.c:1070:3,
      inlined from ‘ref_transaction_update’ at refs.c:1099:2,
      inlined from ‘ref_transaction_verify’ at refs.c:1137:9:
  hash.h:262:9: error: argument 2 null where non-null expected [-Werror=nonnull]
    262 |         memcpy(dst->hash, src->hash, GIT_MAX_RAWSZ);
        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  In file included from git-compat-util.h:185,
                   from cache.h:4,
                   from refs.c:5:
  refs.c: In function ‘ref_transaction_verify’:
  /usr/include/string.h:43:14: note: in a call to function ‘memcpy’ declared ‘nonnull’
     43 | extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
        |              ^~~~~~
  cc1: all warnings being treated as errors

So there is at least one case we'd have potentially missed.

> I don't have any practical use for this now. We could squeeze some
> slight performance out of one CI jobs, but perhaps it'll be more
> interesting in the future.

I don't think the performance of the pedantic CI job is all that interesting. But if we did want to reduce it, it seems like the simplest thing is to just build with pedantic for the regular Linux build? If we're usually pedantic-clean (and we are due to the exceptions in config.mak.dev), then it doesn't hurt to just build and test with that flag.

-Peff