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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux