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

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

[Ævar Arnfjörð Bjarmason]

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?

The gcc manpage suggests that it would, saying:

    Check the code for syntax errors, but don't do anything beyond that

Whereas clang's says:

    Run the preprocessor, parser and type checking stages. 

I think gcc's is a case of its docs drifting out of sync with the
implementation. Both will warn on e.g. this program under -pedantic,
which gcc wouldn't be doing if it only did syntax parsing (and didn't
run the warning machinery):
    
    int main(void)
    {
            int v[0];
            return 0;
    }

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.

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

[Jeff King]

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

> 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