{"thread":{"id":"57740","subject":"[PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","startedAt":"2022-04-15T12:42:05Z","lastAt":"2022-04-16T14:23:36Z","messageCount":25,"participants":["Carlo Marcelo Arenas Belón","Ævar Arnfjörð Bjarmason","Phillip Wood","Junio C Hamano","Carlo Arenas"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"453695","messageId":"20220415123922.30926-1-carenas@gmail.com","threadId":"57740","inReplyTo":null,"subject":"[PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-15T12:39:22Z","receivedAt":"2022-04-15T12:42:05Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"Fedora 36 is scheduled to be released in Apr 19th, but it includes\na prerelease of gcc 12 that has known issues[1] with our codebase\nand therefore requires extra changes to not break a DEVELOPER=1\nbuild.\n\nLock the CI job to the current release image, and while at it rename\nthe job to better reflect what it is currently doing, instead of its\noriginal objective.\n\nFinally add git which was a known[2] issue for a while.\n\n[1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/\n[2] https://lore.kernel.org/git/xmqqeeb1dumx.fsf@gitster.g/\n\nSigned-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n---\nThis merges fine to master, maint and next but will need some work to\nget into seen.\n\nAlternatively, the fixes to fix the build could be merged instead, but\nit will still require at least one temporary change to disable a flag\nas the underlying bug[3] is yet to be addressed in gcc (or somewhere\nelse in Fedora).\n\n[3] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n\n .github/workflows/main.yml        | 4 ++--\n ci/install-docker-dependencies.sh | 4 ++--\n ci/run-build-and-tests.sh         | 3 +--\n 3 files changed, 5 insertions(+), 6 deletions(-)\n\ndiff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\nindex c35200defb9..48e212f4110 100644\n--- a/.github/workflows/main.yml\n+++ b/.github/workflows/main.yml\n@@ -282,8 +282,8 @@ jobs:\n         - jobname: linux32\n           os: ubuntu32\n           image: daald/ubuntu32:xenial\n-        - jobname: pedantic\n-          image: fedora\n+        - jobname: fedora\n+          image: fedora:35\n     env:\n       jobname: ${{matrix.vector.jobname}}\n     runs-on: ubuntu-latest\ndiff --git a/ci/install-docker-dependencies.sh b/ci/install-docker-dependencies.sh\nindex 78b7e326da6..660e25d1d26 100755\n--- a/ci/install-docker-dependencies.sh\n+++ b/ci/install-docker-dependencies.sh\n@@ -15,8 +15,8 @@ linux-musl)\n \tapk add --update build-base curl-dev openssl-dev expat-dev gettext \\\n \t\tpcre2-dev python3 musl-libintl perl-utils ncurses >/dev/null\n \t;;\n-pedantic)\n+fedora)\n \tdnf -yq update >/dev/null &&\n-\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n+\tdnf -yq install make gcc git findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n \t;;\n esac\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex 280dda7d285..de0f8d36d7c 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -37,10 +37,9 @@ linux-clang)\n linux-sha256)\n \texport GIT_TEST_DEFAULT_HASH=sha256\n \t;;\n-pedantic)\n+fedora)\n \t# Don't run the tests; we only care about whether Git can be\n \t# built.\n-\texport DEVOPTS=pedantic\n \texport MAKE_TARGETS=all\n \t;;\n esac\n-- \n2.36.0.rc2.283.gbef64175c85\n\n"},{"id":"453698","messageId":"220415.86wnfqbhsf.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"20220415123922.30926-1-carenas@gmail.com","subject":"Re: [PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-15T13:17:09Z","receivedAt":"2022-04-15T13:25:31Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Carlo Marcelo Arenas Belón wrote:\n\n> Fedora 36 is scheduled to be released in Apr 19th, but it includes\n> a prerelease of gcc 12 that has known issues[1] with our codebase\n> and therefore requires extra changes to not break a DEVELOPER=1\n> build.\n>\n> Lock the CI job to the current release image, and while at it rename\n> the job to better reflect what it is currently doing, instead of its\n> original objective.\n\nThe CI job was added in your cebead1ebfb (ci: run a pedantic build as\npart of the GitHub workflow, 2021-08-08), and later in 6a8cbc41bac\n(developer: enable pedantic by default, 2021-09-03) we made \"pedantic\"\nthe default.\n\nIs there any point in having this job at all anymore, or is it just a\n\"does it compile on Fedora?\" now?\n\nYour cebead1ebfb notes that its gcc is ahead of the curve, if that's\nwhat we actually want perhaps s/fedora/linux-newer-gcc/ ?\n\nI think this change would be much clearer if we first delete the\nnow-redundant pedantic flag, and then later do whatever else that's\nneeded...\n\n> [...]\n> This merges fine to master, maint and next but will need some work to\n> get into seen.\n>\n> Alternatively, the fixes to fix the build could be merged instead, but\n> it will still require at least one temporary change to disable a flag\n> as the underlying bug[3] is yet to be addressed in gcc (or somewhere\n> else in Fedora).\n\nI get the same thing on GCC12 on Debian.\n\nWouldn't a much more useful thing be to upgrade to gcc12 anyway, and\njust set -Wno-error=stringop-overread on gcc12 for dir.(o|s|sp)? Then\nwe'd find any future issues, and blacklist this one known issue...\n\nOr just set -O1 under the same condition.\n\n> diff --git a/ci/install-docker-dependencies.sh b/ci/install-docker-dependencies.sh\n> index 78b7e326da6..660e25d1d26 100755\n> --- a/ci/install-docker-dependencies.sh\n> +++ b/ci/install-docker-dependencies.sh\n> @@ -15,8 +15,8 @@ linux-musl)\n>  \tapk add --update build-base curl-dev openssl-dev expat-dev gettext \\\n>  \t\tpcre2-dev python3 musl-libintl perl-utils ncurses >/dev/null\n>  \t;;\n> -pedantic)\n> +fedora)\n>  \tdnf -yq update >/dev/null &&\n> -\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n> +\tdnf -yq install make gcc git findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n\nWhy do we need to install \"git\" now, I'd think because we're upgrading,\nbut here we're pinning the old version, what changed?\n\n>  \t;;\n>  esac\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index 280dda7d285..de0f8d36d7c 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -37,10 +37,9 @@ linux-clang)\n>  linux-sha256)\n>  \texport GIT_TEST_DEFAULT_HASH=sha256\n>  \t;;\n> -pedantic)\n> +fedora)\n>  \t# Don't run the tests; we only care about whether Git can be\n>  \t# built.\n> -\texport DEVOPTS=pedantic\n>  \texport MAKE_TARGETS=all\n>  \t;;\n>  esac\n\n"},{"id":"453703","messageId":"e9e491d3-eec9-0a30-2e9d-99f1b0d25519@talktalk.net","threadId":"57740","inReplyTo":"20220415123922.30926-1-carenas@gmail.com","subject":"Re: [PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2022-04-15T13:50:49Z","receivedAt":"2022-04-15T13:51:57Z","isPatch":true,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Carlo\n\nOn 15/04/2022 13:39, Carlo Marcelo Arenas Belón wrote:\n> Fedora 36 is scheduled to be released in Apr 19th, but it includes\n> a prerelease of gcc 12 that has known issues[1]\n\nI was confused as that thread seems to be about errors when compiling \nwith -O3 rather than -O2 but your fedora bug report[1] indicates that \nthere are in fact problems when compiling with -O2 which will affect our ci.\n\n> with our codebase\n> and therefore requires extra changes to not break a DEVELOPER=1\n> build.\n> \n> Lock the CI job to the current release image, and while at it rename\n> the job to better reflect what it is currently doing, instead of its\n> original objective.\n> \n> Finally add git which was a known[2] issue for a while.\n\nIt would be useful to explain what the issue is, that email also \nmentions running the tests under this job but we're not doing that here.\n\nThanks for fixing this before it breaks everyone's ci runs\n\nPhillip\n\n[1] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n\n> [1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/\n> [2] https://lore.kernel.org/git/xmqqeeb1dumx.fsf@gitster.g/\n> \n> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n> ---\n> This merges fine to master, maint and next but will need some work to\n> get into seen.\n> \n> Alternatively, the fixes to fix the build could be merged instead, but\n> it will still require at least one temporary change to disable a flag\n> as the underlying bug[3] is yet to be addressed in gcc (or somewhere\n> else in Fedora).\n> \n> [3] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n> \n>   .github/workflows/main.yml        | 4 ++--\n>   ci/install-docker-dependencies.sh | 4 ++--\n>   ci/run-build-and-tests.sh         | 3 +--\n>   3 files changed, 5 insertions(+), 6 deletions(-)\n> \n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index c35200defb9..48e212f4110 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -282,8 +282,8 @@ jobs:\n>           - jobname: linux32\n>             os: ubuntu32\n>             image: daald/ubuntu32:xenial\n> -        - jobname: pedantic\n> -          image: fedora\n> +        - jobname: fedora\n> +          image: fedora:35\n>       env:\n>         jobname: ${{matrix.vector.jobname}}\n>       runs-on: ubuntu-latest\n> diff --git a/ci/install-docker-dependencies.sh b/ci/install-docker-dependencies.sh\n> index 78b7e326da6..660e25d1d26 100755\n> --- a/ci/install-docker-dependencies.sh\n> +++ b/ci/install-docker-dependencies.sh\n> @@ -15,8 +15,8 @@ linux-musl)\n>   \tapk add --update build-base curl-dev openssl-dev expat-dev gettext \\\n>   \t\tpcre2-dev python3 musl-libintl perl-utils ncurses >/dev/null\n>   \t;;\n> -pedantic)\n> +fedora)\n>   \tdnf -yq update >/dev/null &&\n> -\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n> +\tdnf -yq install make gcc git findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n>   \t;;\n>   esac\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index 280dda7d285..de0f8d36d7c 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -37,10 +37,9 @@ linux-clang)\n>   linux-sha256)\n>   \texport GIT_TEST_DEFAULT_HASH=sha256\n>   \t;;\n> -pedantic)\n> +fedora)\n>   \t# Don't run the tests; we only care about whether Git can be\n>   \t# built.\n> -\texport DEVOPTS=pedantic\n>   \texport MAKE_TARGETS=all\n>   \t;;\n>   esac\n\n"},{"id":"453717","messageId":"xmqqwnfqci6f.fsf@gitster.g","threadId":"57740","inReplyTo":"20220415123922.30926-1-carenas@gmail.com","subject":"Re: [PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-15T18:31:20Z","receivedAt":"2022-04-15T18:31:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:\n\n> Fedora 36 is scheduled to be released in Apr 19th, but it includes\n> a prerelease of gcc 12 that has known issues[1] with our codebase\n> and therefore requires extra changes to not break a DEVELOPER=1\n> build.\n>\n> Lock the CI job to the current release image, and while at it rename\n> the job to better reflect what it is currently doing, instead of its\n> original objective.\n\nPlease spell out what \"original objective\" is, why we are changing\nthe purpose of the target, and how such a change is justifiable.\n\nI've always thought that the original objective was to try to see if\nwe still compile with the \"-pedantic\" option on.  Is it now \"we want\nto make sure a recent but not latest version of Fedora is OK\"?  Why\ndo we want to do so?\n\nPlease write your log message with an explicit focus to help the\nfuture developers decide, when they want to bump the version from 35\nto say 40 in the future, if it does or does not violate the spirit\nof this change.\n\n> Finally add git which was a known[2] issue for a while.\n\nInstead of referring to an external message, spell it out, it is not\nall that long.\n\n    Without working \"git\" installed, \"save_good_tree\" step in the CI\n    were not running correctly at all.  This was originally noticed\n    in [2]; take the fix suggested there.\n\nAll in all, each of these three independent and unrelated changes\nmay individually be a good thing to do on its own (or may not be),\ni.e.\n\n * Avoid fedora 36 and later at least for now\n * Do not build with pedantic any more\n * Install \"git\" to help \"save_good_tree\" step in the CI\n\nbut they are unrelated changes that deserves their own justification.\n\n\n> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml\n> index c35200defb9..48e212f4110 100644\n> --- a/.github/workflows/main.yml\n> +++ b/.github/workflows/main.yml\n> @@ -282,8 +282,8 @@ jobs:\n>          - jobname: linux32\n>            os: ubuntu32\n>            image: daald/ubuntu32:xenial\n> -        - jobname: pedantic\n> -          image: fedora\n> +        - jobname: fedora\n> +          image: fedora:35\n>      env:\n>        jobname: ${{matrix.vector.jobname}}\n>      runs-on: ubuntu-latest\n> diff --git a/ci/install-docker-dependencies.sh b/ci/install-docker-dependencies.sh\n> index 78b7e326da6..660e25d1d26 100755\n> --- a/ci/install-docker-dependencies.sh\n> +++ b/ci/install-docker-dependencies.sh\n> @@ -15,8 +15,8 @@ linux-musl)\n>  \tapk add --update build-base curl-dev openssl-dev expat-dev gettext \\\n>  \t\tpcre2-dev python3 musl-libintl perl-utils ncurses >/dev/null\n>  \t;;\n> -pedantic)\n> +fedora)\n>  \tdnf -yq update >/dev/null &&\n> -\tdnf -yq install make gcc findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n> +\tdnf -yq install make gcc git findutils diffutils perl python3 gettext zlib-devel expat-devel openssl-devel curl-devel pcre2-devel >/dev/null\n>  \t;;\n>  esac\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index 280dda7d285..de0f8d36d7c 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -37,10 +37,9 @@ linux-clang)\n>  linux-sha256)\n>  \texport GIT_TEST_DEFAULT_HASH=sha256\n>  \t;;\n> -pedantic)\n> +fedora)\n>  \t# Don't run the tests; we only care about whether Git can be\n>  \t# built.\n> -\texport DEVOPTS=pedantic\n>  \texport MAKE_TARGETS=all\n>  \t;;\n>  esac\n"},{"id":"453725","messageId":"CAPUEspgsfn71JEM5mdG2u9vO6YgEhvdZqtixW9kVyOetqz8RWQ@mail.gmail.com","threadId":"57740","inReplyTo":"xmqqwnfqci6f.fsf@gitster.g","subject":"Re: [PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-15T21:03:16Z","receivedAt":"2022-04-15T21:03:31Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Apr 15, 2022 at 11:31 AM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:\n>\n> > Fedora 36 is scheduled to be released in Apr 19th, but it includes\n> > a prerelease of gcc 12 that has known issues[1] with our codebase\n> > and therefore requires extra changes to not break a DEVELOPER=1\n> > build.\n> >\n> > Lock the CI job to the current release image, and while at it rename\n> > the job to better reflect what it is currently doing, instead of its\n> > original objective.\n>\n> Please spell out what \"original objective\" is, why we are changing\n> the purpose of the target, and how such a change is justifiable.\n\nWill do in a reroll with the objective of \"let's make the pedantic job\nmore useful\" but that is IMHO less of a priority and orthogonal to the\nobjective of this series which was \"let's avoid breaking our CI\nbecause of fedora's gcc updates\".\n\nOriginal I had that done on top of ab/http-gcc-12-workaround (which\nfixes a real, albeit likely harmless bug that compiler was surfacing,\nand that will also break our CI in a few days) but after the feedback\nfrom this thread, think might be preferred and also less likely to\nconflict with current seen.\n\nWould that be reasonable, eventhough it is so late in the RC cycle?\n\nCarlo\n"},{"id":"453728","messageId":"xmqqee1yat0g.fsf@gitster.g","threadId":"57740","inReplyTo":"CAPUEspgsfn71JEM5mdG2u9vO6YgEhvdZqtixW9kVyOetqz8RWQ@mail.gmail.com","subject":"Re: [PATCH] ci: lock \"pedantic\" job into fedora 35 and other cleanup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-15T22:20:15Z","receivedAt":"2022-04-15T22:20:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Arenas <carenas@gmail.com> writes:\n\n> Would that be reasonable, eventhough it is so late in the RC cycle?\n\nI do not think we will take anything like to the release next week;\nit is way way too late for that.  But if it can preview sooner in\n'seen' to help review by others, that would still be good thing to\naim for, I would think.\n\nThanks.\n"},{"id":"453735","messageId":"20220415231342.35980-2-carenas@gmail.com","threadId":"57740","inReplyTo":"20220415231342.35980-1-carenas@gmail.com","subject":"[PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-15T23:13:41Z","receivedAt":"2022-04-15T23:14:08Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"Originally noticed by Peff[1], but yet to be corrected[2] and planned to\nbe released with Fedora 36 (scheduled for Apr 19).\n\n  dir.c: In function ‘git_url_basename’:\n  dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread]\n   3085 |         if (memchr(start, '/', end - start) == NULL\n        |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nFedora is used as part of the CI, and therefore that release will trigger\nfailures, unless the version of the image used is locked to an older\nrelease, as an alternative.\n\nRestricting the flag to the affected source file, as well as implementing\nan independent facility to track these workarounds was specifically punted\nto minimize the risk of introducing problems so close to a release.\n\nThis change should be reverted once the underlying gcc bug is solved and\nwhich should be visible by NOT triggering a warning, otherwise.\n\n[1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/\n[2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n\nSigned-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n---\n config.mak.dev | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/config.mak.dev b/config.mak.dev\nindex 3deb076d5e3..335efd46203 100644\n--- a/config.mak.dev\n+++ b/config.mak.dev\n@@ -65,4 +65,9 @@ DEVELOPER_CFLAGS += -Wno-uninitialized\n endif\n endif\n \n+# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n+ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n+DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n+endif\n+\n GIT_TEST_PERL_FATAL_WARNINGS = YesPlease\n-- \n2.36.0.rc2.283.gbef64175c85\n\n"},{"id":"453736","messageId":"20220415231342.35980-1-carenas@gmail.com","threadId":"57740","inReplyTo":"20220415123922.30926-1-carenas@gmail.com","subject":"[PATCH 0/2] ci: avoid failures for pedantic job with fedora 36","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-15T23:13:40Z","receivedAt":"2022-04-15T23:14:12Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"This series makes a hopeful safe attempt to workaround issues that will\naffect the pedantic CI job after Fedora 36 gets released, and that could\nbe alternatively handled by locking that job to keep using Fedora 35\nuntil all issues with gcc 12 (which is used as the system compiler) are\naddressed.\n\nCarlo Marcelo Arenas Belón (2):\n  config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job\n  config.mak.dev: alternative workaround to gcc 12 warning in http.c\n\n config.mak.dev | 6 ++++++\n 1 file changed, 6 insertions(+)\n\n-- \n2.36.0.rc2.283.gbef64175c85\n\n"},{"id":"453737","messageId":"20220415231342.35980-3-carenas@gmail.com","threadId":"57740","inReplyTo":"20220415231342.35980-1-carenas@gmail.com","subject":"[PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2022-04-15T23:13:42Z","receivedAt":"2022-04-15T23:14:14Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"This provides a \"no code change needed\" option to the \"fix\" currently\nqueued as part of ab/http-gcc-12-workaround and therefore should be\nreverted once that gets merged.\n\nSigned-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n---\n config.mak.dev | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/config.mak.dev b/config.mak.dev\nindex 335efd46203..c3104f400b2 100644\n--- a/config.mak.dev\n+++ b/config.mak.dev\n@@ -68,6 +68,7 @@ endif\n # https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n+DEVELOPER_CFLAGS += -Wno-error=dangling-pointer\n endif\n \n GIT_TEST_PERL_FATAL_WARNINGS = YesPlease\n-- \n2.36.0.rc2.283.gbef64175c85\n\n"},{"id":"453738","messageId":"xmqqh76taplg.fsf@gitster.g","threadId":"57740","inReplyTo":"20220415231342.35980-3-carenas@gmail.com","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-15T23:34:03Z","receivedAt":"2022-04-15T23:34:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:\n\n> This provides a \"no code change needed\" option to the \"fix\" currently\n> queued as part of ab/http-gcc-12-workaround and therefore should be\n> reverted once that gets merged.\n>\n> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n> ---\n>  config.mak.dev | 1 +\n>  1 file changed, 1 insertion(+)\n>\n> diff --git a/config.mak.dev b/config.mak.dev\n> index 335efd46203..c3104f400b2 100644\n> --- a/config.mak.dev\n> +++ b/config.mak.dev\n> @@ -68,6 +68,7 @@ endif\n>  # https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n>  ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n>  DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n> +DEVELOPER_CFLAGS += -Wno-error=dangling-pointer\n>  endif\n>  \n>  GIT_TEST_PERL_FATAL_WARNINGS = YesPlease\n\nHmph, this might be an acceptable workaround to squelch the compiler\nthat complains \"you stored an onstack pointer in a structure and\nthen you are leaving the scope\".  We should do something more like\nthe attached patch, with or without the gcc warning, I think.  We\nmay have smuggled the pointer to finished in slot->finished pointer\nthat survives the current stackframe out of the function in the\noriginal code, so that is what we rectify by clearing the member\nwhen it has the value we stored.\n\n\n http.c | 3 +++\n 1 file changed, 3 insertions(+)\n\ndiff --git c/http.c w/http.c\nindex 229da4d148..85437b1980 100644\n--- c/http.c\n+++ w/http.c\n@@ -1367,6 +1367,9 @@ void run_active_slot(struct active_request_slot *slot)\n \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n \t\t}\n \t}\n+\n+\tif (slot->finished == &finished)\n+\t\tslot->finished = NULL;\n }\n \n static void release_active_slot(struct active_request_slot *slot)\n"},{"id":"453740","messageId":"220416.8635idc3mk.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"20220415231342.35980-2-carenas@gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-15T23:41:27Z","receivedAt":"2022-04-15T23:45:55Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Carlo Marcelo Arenas Belón wrote:\n\n> Originally noticed by Peff[1], but yet to be corrected[2] and planned to\n> be released with Fedora 36 (scheduled for Apr 19).\n>\n>   dir.c: In function ‘git_url_basename’:\n>   dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread]\n>    3085 |         if (memchr(start, '/', end - start) == NULL\n>         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>\n> Fedora is used as part of the CI, and therefore that release will trigger\n> failures, unless the version of the image used is locked to an older\n> release, as an alternative.\n>\n> Restricting the flag to the affected source file, as well as implementing\n> an independent facility to track these workarounds was specifically punted\n> to minimize the risk of introducing problems so close to a release.\n>\n> This change should be reverted once the underlying gcc bug is solved and\n> which should be visible by NOT triggering a warning, otherwise.\n>\n> [1] https://lore.kernel.org/git/YZQhLh2BU5Hquhpo@coredump.intra.peff.net/\n> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n>\n> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>\n> ---\n>  config.mak.dev | 5 +++++\n>  1 file changed, 5 insertions(+)\n>\n> diff --git a/config.mak.dev b/config.mak.dev\n> index 3deb076d5e3..335efd46203 100644\n> --- a/config.mak.dev\n> +++ b/config.mak.dev\n> @@ -65,4 +65,9 @@ DEVELOPER_CFLAGS += -Wno-uninitialized\n>  endif\n>  endif\n>  \n> +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n> +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n> +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n> +endif\n\nWhat I meant with \"just set -Wno-error=stringop-overread on gcc12 for\ndir.(o|s|sp)?\" was that you can set this per-file:\n\n\tdir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n\nDitto for the warning suppression in 2/2, we don't currently have any\nother warnings like this, but we can suppress them more narrowly.\n"},{"id":"453741","messageId":"xmqqbkx1aojp.fsf@gitster.g","threadId":"57740","inReplyTo":"20220415231342.35980-2-carenas@gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-15T23:56:42Z","receivedAt":"2022-04-15T23:56:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:\n\n> Originally noticed by Peff[1], but yet to be corrected[2] and planned to\n> be released with Fedora 36 (scheduled for Apr 19).\n>\n>   dir.c: In function ‘git_url_basename’:\n>   dir.c:3085:13: error: ‘memchr’ specified bound [9223372036854775808, 0] exceeds maximum object size 9223372036854775807 [-Werror=stringop-overread]\n>    3085 |         if (memchr(start, '/', end - start) == NULL\n>         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nI've seen this one; is this accepted on their side that the compiler\nis hurting us with a false positive here?\n\n> +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n> +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n> +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n> +endif\n\nIf this does not break the build further, and it makes the -Werror\nbuild succeed, I wouldn't be too much worried.  I think this one and\nthe other one are innocuous enough that they can be fast-tracked.\n\nThanks.\n"},{"id":"453743","messageId":"CAPUEspj4zu-59qxoVPMDGwMvWmu977WRDe7=t0if7raz=H24AQ@mail.gmail.com","threadId":"57740","inReplyTo":"xmqqh76taplg.fsf@gitster.g","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-16T00:02:57Z","receivedAt":"2022-04-16T00:03:12Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Apr 15, 2022 at 4:34 PM Junio C Hamano <gitster@pobox.com> wrote:\n> diff --git c/http.c w/http.c\n> index 229da4d148..85437b1980 100644\n> --- c/http.c\n> +++ w/http.c\n> @@ -1367,6 +1367,9 @@ void run_active_slot(struct active_request_slot *slot)\n>                         select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n>                 }\n>         }\n> +\n> +       if (slot->finished == &finished)\n> +               slot->finished = NULL;\n>  }\n>\n>  static void release_active_slot(struct active_request_slot *slot)\n\nthis would be IMHO a better fix than the one currently queued in\nab/http-gcc-12-workaround and indeed squashes the warning with the gcc\n12 version that is likely to be released with Fedora 36, but notice\nthat it was proposed before[1] and apparently didn't work with the\nversion of the compiler that Ævar was using at that time, as\ndocumented in the commit message.\n\nEither way, my hope is (assuming this series will go earlier than the\nother one), that a revert to this commit is included at the end of\nab/http-gcc-12-workaround, instead of adding any code changes to this\nseries.\n\nCarlo\n\n[1] https://lore.kernel.org/git/xmqq8rv2nggn.fsf@gitster.g/\n"},{"id":"453744","messageId":"CAPUEspgYU_797VSsdLWVqLXjSYsKfJhUb7M=jdouF01kHcKQyA@mail.gmail.com","threadId":"57740","inReplyTo":"220416.8635idc3mk.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-16T00:08:14Z","receivedAt":"2022-04-16T00:08:31Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Apr 15, 2022 at 4:45 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Fri, Apr 15 2022, Carlo Marcelo Arenas Belón wrote:\n> > diff --git a/config.mak.dev b/config.mak.dev\n> > index 3deb076d5e3..335efd46203 100644\n> > --- a/config.mak.dev\n> > +++ b/config.mak.dev\n> > @@ -65,4 +65,9 @@ DEVELOPER_CFLAGS += -Wno-uninitialized\n> >  endif\n> >  endif\n> >\n> > +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n> > +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n> > +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n> > +endif\n>\n> What I meant with \"just set -Wno-error=stringop-overread on gcc12 for\n> dir.(o|s|sp)?\" was that you can set this per-file:\n\nof course, but that change goes in the Makefile and therefore affects\nALL builds, this one only affects DEVELOPER=1 and is therefore more\nnarrow.\n\nthat is what I meant with \"has been punted\" in my commit message.\n\n>         dir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n\nI know at least one developer that will then rightfully complain that\nthe git build doesn't work in AIX with xl after this.\n\nCarlo\n"},{"id":"453745","messageId":"xmqq35idanh6.fsf@gitster.g","threadId":"57740","inReplyTo":"220416.8635idc3mk.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-16T00:19:49Z","receivedAt":"2022-04-16T00:20:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> What I meant with \"just set -Wno-error=stringop-overread on gcc12 for\n> dir.(o|s|sp)?\" was that you can set this per-file:\n>\n> \tdir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n>\n> Ditto for the warning suppression in 2/2, we don't currently have any\n> other warnings like this, but we can suppress them more narrowly.\n\nWhile it is certainly attractive if we can loosen the warning\nsettings in a more pointed way, is it easy to arrange something like\nthe above ONLY for gcc12 and no other compilers?  \n\nDo we know -Wno-error=i-have-no-idea-what-that-error-is safely gets\nignored by all compilers we care about, which may not even be a GCC?\n"},{"id":"453746","messageId":"xmqqwnfp98ix.fsf@gitster.g","threadId":"57740","inReplyTo":"CAPUEspj4zu-59qxoVPMDGwMvWmu977WRDe7=t0if7raz=H24AQ@mail.gmail.com","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-16T00:28:06Z","receivedAt":"2022-04-16T00:28:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlo Arenas <carenas@gmail.com> writes:\n\n> this would be IMHO a better fix than the one currently queued in\n> ab/http-gcc-12-workaround and indeed squashes the warning with the gcc\n> 12 version that is likely to be released with Fedora 36, \n\nThat is an excellent news, as ...\n\n> but notice\n> that it was proposed before[1] and apparently didn't work with the\n> version of the compiler that Ævar was using at that time, as\n> documented in the commit message.\n\n... I was the one who suggested it, and I remember that it didn't\nwork for Ævar back then.  If the problem with the version Ævar had\nis no longer there, that does sound like a good thing.  We can take\nthe patch you posted and then post release we can apply the \"clear\nthe .finished member as we are done with the slot\" fix, which is a\ngood hygiene regardless of any compiler warning issue.\n\n> Either way, my hope is (assuming this series will go earlier than the\n> other one), that a revert to this commit is included at the end of\n> ab/http-gcc-12-workaround, instead of adding any code changes to this\n> series.\n\nAt this point, my inclination is to merge these two DEVELOPER_CFLAGS\nchanges before the 2.36 final gets tagged.\n\nThanks.\n"},{"id":"453747","messageId":"220416.86lew5akh1.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"xmqqwnfp98ix.fsf@gitster.g","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-16T01:20:17Z","receivedAt":"2022-04-16T02:03:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Junio C Hamano wrote:\n\n> Carlo Arenas <carenas@gmail.com> writes:\n>\n>> this would be IMHO a better fix than the one currently queued in\n>> ab/http-gcc-12-workaround and indeed squashes the warning with the gcc\n>> 12 version that is likely to be released with Fedora 36, \n>\n> That is an excellent news, as ...\n>\n>> but notice\n>> that it was proposed before[1] and apparently didn't work with the\n>> version of the compiler that Ævar was using at that time, as\n>> documented in the commit message.\n>\n> ... I was the one who suggested it, and I remember that it didn't\n> work for Ævar back then.  If the problem with the version Ævar had\n> is no longer there, that does sound like a good thing.  We can take\n> the patch you posted and then post release we can apply the \"clear\n> the .finished member as we are done with the slot\" fix, which is a\n> good hygiene regardless of any compiler warning issue.\n\nI don't know what version of GCC 12 Carlo is using, but I'm using it\nbuilt from its main branch this week, and it warns on that \"if\n(slot->finished == &finished)\" suggestion.\n\nI don't understand what you think you're gaining from:\n\n\tif (slot->finished == &finished)\n\t\tslot->finished = NULL;\n\nThat you don't get from:\n\n\tslot->finished = NULL;\n\nI.e. the assignment earlier in the function is unconditional, why\nwouldn't the clearing of the data correspond to that assignment and\nclear it unconditionally?\n\nIf it's imagined that we have parallel assignments of the \"finished\"\nmember wouldn't that check/assignment be racy?\n"},{"id":"453751","messageId":"220416.86tuatalmf.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"CAPUEspgYU_797VSsdLWVqLXjSYsKfJhUb7M=jdouF01kHcKQyA@mail.gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-16T00:55:18Z","receivedAt":"2022-04-16T02:06:33Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Carlo Arenas wrote:\n\n> On Fri, Apr 15, 2022 at 4:45 PM Ævar Arnfjörð Bjarmason\n> <avarab@gmail.com> wrote:\n>> On Fri, Apr 15 2022, Carlo Marcelo Arenas Belón wrote:\n>> > diff --git a/config.mak.dev b/config.mak.dev\n>> > index 3deb076d5e3..335efd46203 100644\n>> > --- a/config.mak.dev\n>> > +++ b/config.mak.dev\n>> > @@ -65,4 +65,9 @@ DEVELOPER_CFLAGS += -Wno-uninitialized\n>> >  endif\n>> >  endif\n>> >\n>> > +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n>> > +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n>> > +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n>> > +endif\n>>\n>> What I meant with \"just set -Wno-error=stringop-overread on gcc12 for\n>> dir.(o|s|sp)?\" was that you can set this per-file:\n>\n> of course, but that change goes in the Makefile and therefore affects\n> ALL builds, this one only affects DEVELOPER=1 and is therefore more\n> narrow.\n>\n> that is what I meant with \"has been punted\" in my commit message.\n\nI mean it can go in config.mak.dev, it doesn't need to be in the\nMakefile itself.\n\nThe make doesn't have any notion of \"file scope\" or similar, the\nbehavior is just a union of the variables, rules etc. that you source.\n\nSo just as we append to DEVELOPER_CFLAGS and the Makefile uses it we can\nsay \"only append this to this file's flags\", which since it's in\nconfig.mak.dev is guarded by DEVELOPER.\n\n>>         dir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n>\n> I know at least one developer that will then rightfully complain that\n> the git build doesn't work in AIX with xl after this.\n\nYes, it would break if it were in the Makfile, but not if it's in\nconfig.mak.dev.\n\nThere it'll be guarded by the \"only for gcc12\" clause, so we don't need\nto worry about breaking any other compiler.\n"},{"id":"453752","messageId":"CAPUEsphXnLfnoM6qznVhaxVdOPk-38+Jaj7OEOY7bEvMiDgz3g@mail.gmail.com","threadId":"57740","inReplyTo":"xmqqwnfp98ix.fsf@gitster.g","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2022-04-16T00:51:57Z","receivedAt":"2022-04-16T02:06:33Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Fri, Apr 15, 2022 at 5:28 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Carlo Arenas <carenas@gmail.com> writes:\n>\n> > this would be IMHO a better fix than the one currently queued in\n> > ab/http-gcc-12-workaround and indeed squashes the warning with the gcc\n> > 12 version that is likely to be released with Fedora 36,\n>\n> That is an excellent news, as ...\n\nSadly I botched the test, and was doubly confused because Ævar might\nhave botched it too the same way as he originally reported it\nworked[1] for him, only to say the opposite in the commit message for\nthe reroll.\n\nthe warning is not squashed even if we do the more aggressive BUG if\nnot NULL first and now I am even doubting there was a real bug to\nbegin with.\n\nNeither this one or the previous one had bugs reported to gcc AFAIK,\nuntil I raised[2] the previous one with Fedora, so there is no\nconfirmation either from their side that they are indeed bugs yet.\n\nCarlo\n\n[1] https://lore.kernel.org/git/220127.86mtjhdeme.gmgdl@evledraar.gmail.com/\n[2] https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n"},{"id":"453754","messageId":"xmqq35id970u.fsf@gitster.g","threadId":"57740","inReplyTo":"xmqqwnfp98ix.fsf@gitster.g","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-16T01:00:33Z","receivedAt":"2022-04-16T02:07:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> ...  We can take\n> the patch you posted and then post release we can apply the \"clear\n> the .finished member as we are done with the slot\" fix, which is a\n> good hygiene regardless of any compiler warning issue.\n> ...\n> At this point, my inclination is to merge these two DEVELOPER_CFLAGS\n> changes before the 2.36 final gets tagged.\n\nSo, the post release longer term clean-up with log message may look\nlike this.\n\n----- >8 --------- >8 --------- >8 --------- >8 -----\nSubject: [PATCH] http.c: clear the 'finished' member once we are done with it\n\nIn http.c, the run_active_slot() function allows the given \"slot\" to\nmake progress by calling step_active_slots() in a loop repeatedly,\nand the loop is not left until the request held in the slot\ncompletes.\n\nAges ago, we used to use the slot->in_use member to get out of the\nloop, which misbehaved when the request in \"slot\" completes (at\nwhich time, the result of the request is copied away from the slot,\nand the in_use member is cleared, making the slot ready to be\nreused), and the \"slot\" gets reused to service a different request\n(at which time, the \"slot\" becomes in_use again, even though it is\nfor a different request).  The loop terminating condition mistakenly\nthought that the original request has yet to be completed.\n\nToday's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10)\nfixed this issue, uses a separate \"slot->finished\" member that is\nset in run_active_slot() to point to an on-stack variable, and the\ncode that completes the request in finish_active_slot() clears the\non-stack variable via the pointer to signal that the particular\nrequest held by the slot has completed.  It also clears the in_use\nmember (as before that fix), so that the slot itself can safely be\nreused for an unrelated request.\n\nOne thing that is not quite clean in this arrangement is that,\nunless the slot gets reused, at which point the finished member is\nreset to NULL, the member keeps the value of &finished, which\nbecomes a dangling pointer into the stack when run_active_slot()\nreturns.  In finish_active_slot(), clear the finished member after\nit is used to signal the run_active_slot() caller, because we know\nwe are done with the pointer at that point.\n\nAlso, because compilers may not be able to follow the callchain that\ndeep from run_active_slot() down to finish_active_slot(), clear the\nfinished member but make sure to limit it to the case where the\npointer still points at the on-stack variable of ours (the pointer\nmay be set to point at the on-stack variable of somebody else after\nthe slot gets reused, in which case we do not want to touch it).\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n http.c | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/http.c b/http.c\nindex 229da4d148..626b4051e1 100644\n--- a/http.c\n+++ b/http.c\n@@ -197,8 +197,10 @@ static void finish_active_slot(struct active_request_slot *slot)\n \tclosedown_active_slot(slot);\n \tcurl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);\n \n-\tif (slot->finished != NULL)\n-\t\t(*slot->finished) = 1;\n+\tif (slot->finished != NULL) {\n+\t\t*slot->finished = 1;\n+\t\tslot->finished = NULL;\n+\t}\n \n \t/* Store slot results so they can be read after the slot is reused */\n \tif (slot->results != NULL) {\n@@ -1367,6 +1369,9 @@ void run_active_slot(struct active_request_slot *slot)\n \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n \t\t}\n \t}\n+\n+\tif (slot->finished == &finished)\n+\t\tslot->finished = NULL;\n }\n \n static void release_active_slot(struct active_request_slot *slot)\n-- \n2.36.0-rc2-233-gc1d9011153\n\n"},{"id":"453757","messageId":"220416.86pmlhaktz.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"CAPUEspj4zu-59qxoVPMDGwMvWmu977WRDe7=t0if7raz=H24AQ@mail.gmail.com","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-16T01:08:18Z","receivedAt":"2022-04-16T02:26:43Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Carlo Arenas wrote:\n\n> On Fri, Apr 15, 2022 at 4:34 PM Junio C Hamano <gitster@pobox.com> wrote:\n>> diff --git c/http.c w/http.c\n>> index 229da4d148..85437b1980 100644\n>> --- c/http.c\n>> +++ w/http.c\n>> @@ -1367,6 +1367,9 @@ void run_active_slot(struct active_request_slot *slot)\n>>                         select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n>>                 }\n>>         }\n>> +\n>> +       if (slot->finished == &finished)\n>> +               slot->finished = NULL;\n>>  }\n>>\n>>  static void release_active_slot(struct active_request_slot *slot)\n>\n> this would be IMHO a better fix than the one currently queued in\n> ab/http-gcc-12-workaround and indeed squashes the warning with the gcc\n> 12 version that is likely to be released with Fedora 36, but notice\n> that it was proposed before[1] and apparently didn't work with the\n> version of the compiler that Ævar was using at that time, as\n> documented in the commit message.\n\nDoes it suppress the warning on your GCCv12? It doesn't on mine, as\nnoted later in related threads my \"yes, that does quiet it\" in [1] is a\nmisreport. That doesn't suppress the warning (the [2] patch notes it.\n\n1. https://lore.kernel.org/git/220127.86mtjhdeme.gmgdl@evledraar.gmail.com/\n2. https://lore.kernel.org/git/patch-v3-1.1-69190804c67-20220325T143322Z-avarab@gmail.com/\n"},{"id":"453760","messageId":"xmqqo8117er2.fsf@gitster.g","threadId":"57740","inReplyTo":"220416.86tuatalmf.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-16T05:56:33Z","receivedAt":"2022-04-16T05:56:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Fri, Apr 15 2022, Carlo Arenas wrote:\n>\n>>> > +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n>>> > +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n>>> > +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n>>> > +endif\n>>>\n>>> What I meant with \"just set -Wno-error=stringop-overread on gcc12 for\n>>> dir.(o|s|sp)?\" was that you can set this per-file:\n>>\n>> of course, but that change goes in the Makefile and therefore affects\n>> ...\n> I mean it can go in config.mak.dev, it doesn't need to be in the\n> Makefile itself.\n> ...\n>>>         dir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n>>\n>> I know at least one developer that will then rightfully complain that\n>> the git build doesn't work in AIX with xl after this.\n>\n> Yes, it would break if it were in the Makfile, but not if it's in\n> config.mak.dev.\n\nI do not think you can blame Carlo for poor reading/comprehension in\nthis case---I too (mis)read what you wrote, and didn't realize that\nyou were suggesting to add the \"for these target, EXTRA_CPPFLAGS\nadditionally gets this value\" inside the ifneq/endif Carlo added to\nhold the DEVELOPER_CFLAGS thing.\n\nFor now, let's stick to the simpler form, though.\n\nThanks.\n"},{"id":"453769","messageId":"220416.86czhh9ov0.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"xmqqo8117er2.fsf@gitster.g","subject":"Re: [PATCH 1/2] config.mak.dev: workaround gcc 12 bug affecting \"pedantic\" CI job","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-16T12:33:09Z","receivedAt":"2022-04-16T12:47:38Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> On Fri, Apr 15 2022, Carlo Arenas wrote:\n>>\n>>>> > +# https://bugzilla.redhat.com/show_bug.cgi?id=2075786\n>>>> > +ifneq ($(filter gcc12,$(COMPILER_FEATURES)),)\n>>>> > +DEVELOPER_CFLAGS += -Wno-error=stringop-overread\n>>>> > +endif\n>>>>\n>>>> What I meant with \"just set -Wno-error=stringop-overread on gcc12 for\n>>>> dir.(o|s|sp)?\" was that you can set this per-file:\n>>>\n>>> of course, but that change goes in the Makefile and therefore affects\n>>> ...\n>> I mean it can go in config.mak.dev, it doesn't need to be in the\n>> Makefile itself.\n>> ...\n>>>>         dir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread\n>>>\n>>> I know at least one developer that will then rightfully complain that\n>>> the git build doesn't work in AIX with xl after this.\n>>\n>> Yes, it would break if it were in the Makfile, but not if it's in\n>> config.mak.dev.\n>\n> I do not think you can blame Carlo for poor reading/comprehension in\n> this case---I too (mis)read what you wrote, and didn't realize that\n> you were suggesting to add the \"for these target, EXTRA_CPPFLAGS\n> additionally gets this value\" inside the ifneq/endif Carlo added to\n> hold the DEVELOPER_CFLAGS thing.\n\nIndeed, I don't think I would have understood myself, I didn't mean to\nimply any fault (except my own for not elaborating). Just claifying that\nwe can use that trick.\n\nI.e. my own config.mak has had this (or a form thereof) for a while:\n\n\thttp.sp http.s http.o: EXTRA_CPPFLAGS += -Wno-error=dangling-pointer=\n\tdir.sp dir.s dir.o: EXTRA_CPPFLAGS += -Wno-error=stringop-overread \n\n> For now, let's stick to the simpler form, though.\n\nSure, works for me.\n\nNote though that one important difference between this solution and the\npatch I had for http.c is that the patch will fix things for all builds,\nwhereas a config.mak.dev change (whether it's Carlos's global addition,\nor my per-file) can only do so for cases where DEVELOPER=1.\n\nAlthough in practice that's probably fine, anyone turning on -Werror is\nlikely to do so through DEVELOPER=1, and fore those that don't it's\n\"just a warning\".\n\nSo yeah, it's probably better to do that for now.\n\nBut FWIW I did write up and test the below monstrosity as a replacement\njust now, it's guaranteed to work with/without DEVELOPER, and squashes\nonly that specific warning, and only on GCC:\n\t\n\tdiff --git a/dir.c b/dir.c\n\tindex f2b0f242101..e7a5acb126f 100644\n\t--- a/dir.c\n\t+++ b/dir.c\n\t@@ -3089,6 +3089,13 @@ char *git_url_basename(const char *repo, int is_bundle, int is_bare)\n\t \t * result in a dir '2222' being guessed due to backwards\n\t \t * compatibility.\n\t \t */\n\t+#ifdef __clang__\n\t+#elif defined(__GNUC__)\n\t+#if __GNUC__ >= 12\n\t+#pragma GCC diagnostic push\n\t+#pragma GCC diagnostic ignored \"-Wstringop-overread\"\n\t+#endif\n\t+#endif\n\t \tif (memchr(start, '/', end - start) == NULL\n\t \t    && memchr(start, ':', end - start) != NULL) {\n\t \t\tptr = end;\n\t@@ -3097,6 +3104,12 @@ char *git_url_basename(const char *repo, int is_bundle, int is_bare)\n\t \t\tif (start < ptr && ptr[-1] == ':')\n\t \t\t\tend = ptr - 1;\n\t \t}\n\t+#ifdef __clang__\n\t+#elif defined(__GNUC__)\n\t+#if __GNUC__ >= 12\n\t+#pragma GCC diagnostic pop\n\t+#endif\n\t+#endif\n\t \n\t \t/*\n\t \t * Find last component. To remain backwards compatible we\n\tdiff --git a/http.c b/http.c\n\tindex 229da4d1488..e63d4ab9527 100644\n\t--- a/http.c\n\t+++ b/http.c\n\t@@ -1329,7 +1329,21 @@ void run_active_slot(struct active_request_slot *slot)\n\t \tstruct timeval select_timeout;\n\t \tint finished = 0;\n\t \n\t+#ifdef __clang__\n\t+#elif defined(__GNUC__)\n\t+#if __GNUC__ >= 12\n\t+#pragma GCC diagnostic push\n\t+#pragma GCC diagnostic ignored \"-Wdangling-pointer=\"\n\t+#endif\n\t+#endif\n\t \tslot->finished = &finished;\n\t+#ifdef __clang__\n\t+#elif defined(__GNUC__)\n\t+#if __GNUC__ >= 12\n\t+#pragma GCC diagnostic pop\n\t+#endif\n\t+#endif\n\t+\n\t \twhile (!finished) {\n\t \t\tstep_active_slots();\n\t \nBut yeah, between us not having -Werror by default and DEVELOPER\nhandling it it's probably not worth it just to be able to selectively\nsuppress the warnings involved.\n"},{"id":"453770","messageId":"220416.868rs59ny6.gmgdl@evledraar.gmail.com","threadId":"57740","inReplyTo":"xmqq35id970u.fsf@gitster.g","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-16T12:50:07Z","receivedAt":"2022-04-16T13:07:21Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Apr 15 2022, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> ...  We can take\n>> the patch you posted and then post release we can apply the \"clear\n>> the .finished member as we are done with the slot\" fix, which is a\n>> good hygiene regardless of any compiler warning issue.\n>> ...\n>> At this point, my inclination is to merge these two DEVELOPER_CFLAGS\n>> changes before the 2.36 final gets tagged.\n>\n> So, the post release longer term clean-up with log message may look\n> like this.\n>\n> ----- >8 --------- >8 --------- >8 --------- >8 -----\n\n> [...] clear the\n> finished member but make sure to limit it to the case where the\n> pointer still points at the on-stack variable of ours (the pointer\n> may be set to point at the on-stack variable of somebody else after\n> the slot gets reused, in which case we do not want to touch it).\n\nI'm still not sure I get this. So while we're in the run_active_slot()\nwill we have a nested or concurrent invocation of another\nrun_active_slot() (driven by the curl API?).\n\nMy reading of this code in get_active_slot() is that the \"in_use\" member\nis guard in \"struct active_request_slot\" against any such potential\nshenanigans, even if this was racily running multi-threaded (although\nthen the slot selection loop itself would need some mutexing).\n\nThen in finish_active_slot() we have since baa7b67d091 (HTTP slot reuse\nfixes, 2006-03-10) unconditionally clobbered \"slot->finished\" if it's\nnon-NULL, without any \"is it ours?\" check.\n\nWhich has been my analysis of this, i.e. that at this point we \"own\"\nthat member, and we won't race with anyone. We were even doing the\nunconditional clearing already, it was just across a function\nboundary. But GCC started warning about /how/ we did the clearing, so.\n\nIf it's just general paranoia OK, quite confusing though, because we're\ndoing this in 2 places, and this puts a guard on 1/2.\n\nBut I'm asking in case you see some path through this where \"the slot\ngets reused [by someone else, it's not our value, and] we do not want to\ntouch it\".\n\nI don't see how that could happen *within* run_active_slot() but not\nbetween the existing code between run_active_slot() and\nfinish_active_slot(), which is doing that clearing unconditionally...\n\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  http.c | 9 +++++++--\n>  1 file changed, 7 insertions(+), 2 deletions(-)\n>\n> diff --git a/http.c b/http.c\n> index 229da4d148..626b4051e1 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -197,8 +197,10 @@ static void finish_active_slot(struct active_request_slot *slot)\n>  \tclosedown_active_slot(slot);\n>  \tcurl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);\n>  \n> -\tif (slot->finished != NULL)\n> -\t\t(*slot->finished) = 1;\n> +\tif (slot->finished != NULL) {\n> +\t\t*slot->finished = 1;\n> +\t\tslot->finished = NULL;\n> +\t}\n>  \n>  \t/* Store slot results so they can be read after the slot is reused */\n>  \tif (slot->results != NULL) {\n"},{"id":"453775","messageId":"xmqq1qxx6rab.fsf@gitster.g","threadId":"57740","inReplyTo":"220416.86lew5akh1.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH 2/2] config.mak.dev: alternative workaround to gcc 12 warning in http.c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-16T14:23:24Z","receivedAt":"2022-04-16T14:23:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I.e. the assignment earlier in the function is unconditional, why\n> wouldn't the clearing of the data correspond to that assignment and\n> clear it unconditionally?\n\nThe original problem description that introduced .finished member\nindicates that inside the while() loop, the same slot object can be\ncompleted (by feeding it to finish_active_slot(), which would also\nclears its in_use thus making it reusable) and then later be reused\n(by using it for a different request).\n\nThe dispatching is done by calling step_active_slots() repeatedly\ninside the loop and I do not think there is any multi-threaded\nconcurrency to worry about here.  The protection is against a case\nwhere such a slot, which was originally ours and pointed at our\non-stack finished variable with its finished member, is reused for a\ndifferent request, and its finished member is used in a similar way\nto point at the on-stack finish variable in somebody else's\nstackframe in the future code.  If the slot instance we were using\nas ours upon the entry of this function is being used for another\nrequest already (the fix that required the .finished member is an\nenough explanation that it is a real concern), after we leave the\nloop, the slot instance is no longer ours, so we need to be careful\nwhen we clear it.\n\nAt the entry of this function, the story is vastly different. The\nslot instance belongs to us---the caller chose the slot and decided\nto use it to service a particular request and threw the slot\ninstance at us, so there is nothing wrong to unconditionally use the\n.finished member of the slot and point it at a variable in our\nstackframe.  But after the loop leaves, and the slot may or may not\nbe already reused to hold another request.  If .finished is set and\nit is the value that points at the variable in our stackframe, then\nwe are the only one who could have set that and it is safe to clear.\nAny other value other than NULL, we do not know at that point who\nset it, and it is being used for a request that we have nothing to\ndo with.  That is why we want to refrain from touching it when it is\nnot clearly ours.\n\n\n\n"}]}