{"thread":{"id":"57001","subject":"Will -fsyntax-only hide issues with -pedantic? I think not...","startedAt":"2021-11-30T13:25:01Z","lastAt":"2021-11-30T21:02:35Z","messageCount":2,"participants":["Ævar Arnfjörð Bjarmason","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"442648","messageId":"211130.86ilw9epy3.gmgdl@evledraar.gmail.com","threadId":"57001","inReplyTo":null,"subject":"Will -fsyntax-only hide issues with -pedantic? I think not...","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-30T13:13:11Z","receivedAt":"2021-11-30T13:25:01Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The answer to $subject is not at all urgent, but I noticed we can get\nsome (very modest) speed increases in the \"pedantic\" CI job when adding\n-fsyntax-only to CFLAGS. This currently requires monkeypatching out the\n\"-o <target> -c\" part hardcoded in the Makefile. See cebead1ebfb (ci:\nrun a pedantic build as part of the GitHub workflow, 2021-08-08) for the\npedantic job.\n\nI.e. I'm aware of CFLAGS's -O<n> changing which warings we emit, but\ndoes -fsyntax-only?\n\nThe gcc manpage suggests that it would, saying:\n\n    Check the code for syntax errors, but don't do anything beyond that\n\nWhereas clang's says:\n\n    Run the preprocessor, parser and type checking stages. \n\nI think gcc's is a case of its docs drifting out of sync with the\nimplementation. Both will warn on e.g. this program under -pedantic,\nwhich gcc wouldn't be doing if it only did syntax parsing (and didn't\nrun the warning machinery):\n    \n    int main(void)\n    {\n            int v[0];\n            return 0;\n    }\n\nI don't have any practical use for this now. We could squeeze some\nslight performance out of one CI jobs, but perhaps it'll be more\ninteresting in the future.\n"},{"id":"442683","messageId":"YaaRaM8ApB36A9V2@coredump.intra.peff.net","threadId":"57001","inReplyTo":"211130.86ilw9epy3.gmgdl@evledraar.gmail.com","subject":"Re: Will -fsyntax-only hide issues with -pedantic? I think not...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-30T21:02:32Z","receivedAt":"2021-11-30T21:02:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 30, 2021 at 02:13:11PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> The answer to $subject is not at all urgent, but I noticed we can get\n> some (very modest) speed increases in the \"pedantic\" CI job when adding\n> -fsyntax-only to CFLAGS. This currently requires monkeypatching out the\n> \"-o <target> -c\" part hardcoded in the Makefile. See cebead1ebfb (ci:\n> run a pedantic build as part of the GitHub workflow, 2021-08-08) for the\n> pedantic job.\n> \n> I.e. I'm aware of CFLAGS's -O<n> changing which warings we emit, but\n> does -fsyntax-only?\n\nI've never used -fsyntax-only. But I'd tend to doubt it, though, as I\nwouldn't expect -fsyntax-only to run through the optimizer. And indeed,\nthe recent -O3 problem disappears there:\n\n  $ gcc -fsyntax-only -I. -Wall -Werror -O3 refs.c\n  [no output]\n\n  $ gcc -o /dev/null -c -I. -Wall -Werror -O3 refs.c\n  In file included from hashmap.h:4,\n                   from cache.h:6,\n                   from refs.c:5:\n  In function ‘oidcpy’,\n      inlined from ‘ref_transaction_add_update’ at refs.c:1070:3,\n      inlined from ‘ref_transaction_update’ at refs.c:1099:2,\n      inlined from ‘ref_transaction_verify’ at refs.c:1137:9:\n  hash.h:262:9: error: argument 2 null where non-null expected [-Werror=nonnull]\n    262 |         memcpy(dst->hash, src->hash, GIT_MAX_RAWSZ);\n        |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n  In file included from git-compat-util.h:185,\n                   from cache.h:4,\n                   from refs.c:5:\n  refs.c: In function ‘ref_transaction_verify’:\n  /usr/include/string.h:43:14: note: in a call to function ‘memcpy’ declared ‘nonnull’\n     43 | extern void *memcpy (void *__restrict __dest, const void *__restrict __src,\n        |              ^~~~~~\n  cc1: all warnings being treated as errors\n\nSo there is at least one case we'd have potentially missed.\n\n> I don't have any practical use for this now. We could squeeze some\n> slight performance out of one CI jobs, but perhaps it'll be more\n> interesting in the future.\n\nI don't think the performance of the pedantic CI job is all that\ninteresting. But if we did want to reduce it, it seems like the simplest\nthing is to just build with pedantic for the regular Linux build? If\nwe're usually pedantic-clean (and we are due to the exceptions in\nconfig.mak.dev), then it doesn't hurt to just build and test with that\nflag.\n\n-Peff\n"}]}