release-0.7: switch C++ toolchain to gcc-14#321
Open
vporoshok wants to merge 5 commits intorelease-0.7from
Open
release-0.7: switch C++ toolchain to gcc-14#321vporoshok wants to merge 5 commits intorelease-0.7from
vporoshok wants to merge 5 commits intorelease-0.7from
Conversation
Cherry-picked from pp branch (e207bf7). Required for the migration to gcc-14: -static-libstdc++ already drives static linking of libstdc++, so the explicit -l:libstdc++.a is redundant and breaks on debian-trixie / libstdc++-14 in some configurations. Co-authored-by: Cursor <cursoragent@cursor.com>
Cherry-picked from PR #271 on the pp branch (3df1395, "Gcc 14 clang tidy 21"), restricted to the toolchain registration parts. The shared CI image (registry/prompp/ci-gcc-image:gcc-tools-${arch}) is built only from the pp branch and now ships gcc-14 (debian-trixie). The release-0.7 build was still registering the g++-13 Bazel toolchain, whose builtin_include_directories pointed at /usr/lib/gcc/{x86_64,aarch64}-linux-gnu/13 which no longer exist in the image; on top of that the linker was pulling libstdc++_libbacktrace, which gcc-14 has folded into libstdc++exp. This commit: - registers cc_toolchain_for_g++-14_toolchain_{aarch64,x86_64} in pp/MODULE.bazel, - drops the now-unused g++-13 cc_toolchain_suite / cc_toolchain / toolchain / cc_toolchain_config entries in pp/bazel/toolchain/BUILD, - replaces -lstdc++_libbacktrace with -lstdc++exp in the default linker flags in pp/bazel/toolchain/cc_toolchain_config.bzl. The clang-tidy / GOST-flag changes from PR #271 (which depend on PR #270 "GOST compile flags") are intentionally excluded because they were never back-ported to release-0.7 and would pull in additional warnings that the release branch has not been audited against. Co-authored-by: Cursor <cursoragent@cursor.com>
Cherry-picked from PR #271 on the pp branch (file pp/third_party/patches/ quasis_crypto/0001-md5.hh.patch from 3df1395). gcc-14 rejects the use of the built-in __is_trivially_copyable trait inside a requires-clause ("error: use of built-in trait '__is_trivially_copyable' in function signature; use library traits instead"). The updated patch: - replaces __is_trivially_copyable(T) with std::is_trivially_copyable_v<T> in the requires-clauses of MD5::update overloads, - adds the missing #pragma once and <bit>/<type_traits> includes, - silences a -Wmaybe-uninitialized false positive around hasher.update(). Required to make pp/prometheus tests build under gcc-14. Co-authored-by: Cursor <cursoragent@cursor.com>
Cherry-picked from PR #287 on the pp branch (c80d137) for the production-code parts only. GCC 14's libstdc++ uses sized-range fast paths in std::ranges::equal, which breaks BareBones::GenericBitset because GenericBitset::size() returns the allocated bit width, not ranges::distance(begin, end) (the set-bit count). This caused runtime failures in pp/bare_bones/tests/bitset_tests.cpp (BitsetFixture.random_access, BitsetConstructorsFixture.MoveConstructor / MoveAssignment / MoveAssignmentNonEmpty) and in pp/series_data/tests/querier/{instant_querier,querier}_tests.cpp where the querier returns a Bitset that is then compared against an initializer_list. Specialise std::ranges::disable_sized_range<GenericBitset<R>> = true to restore element-wise comparison. Also update pp/go/cppbridge/entrypoint.go cgo LDFLAGS: -lstdc++_libbacktrace -> -lstdc++exp -l:libstdc++_libbacktrace.a -> -l:libstdc++exp.a GCC 14 has folded libstdc++_libbacktrace into libstdc++exp; without this the go-tests / build-go-bindings step fails to link. Co-authored-by: Cursor <cursoragent@cursor.com>
set_const_labels was sorting label pointers with return a->name < b->name; where a->name and b->name are const String*. This compares stack addresses, not strings, so the resulting iteration order — and therefore MetricDescriptor::id / dim_hash — depended on whatever order the local String objects ended up at on the stack. Under gcc-13 (and under gcc-14 on the pp branch with -fstack-protector- strong from PR #270 GOST flags) the layout happened to match the alphabetical order, so primitives_test/MetricDescriptorFixture.TestWithLabels produced the expected 9433770049495071547 / 1413792954011449091. On release-0.7 under plain gcc-14 the layout reverses, the labels are hashed in the opposite order and the test fails with 8942707084255367343 / 18042764105132557107. Compare the dereferenced strings instead. This matches what the Go prometheus/client_golang side does (sort labels lexicographically by name) and makes id/dim_hash deterministic across compilers / build flags. The expected values in the test correspond to this alphabetical order, so the test goes green. MetricDescriptor::id is computed in the constructor and not persisted, so the only effect of this change at runtime is that two metrics with the same labels but constructed in different process invocations now get the same id (which they already did on pp, just not on release-0.7 under the new compiler). Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The shared CI image
${DEV_REGISTRY}/prompp/ci-gcc-image:gcc-tools-${arch}is built only from theppbranch (see.github/workflows/build-ci-image.yaml) and now ships gcc-14 (debian-trixie). Onrelease-0.7the Bazel build still registered theg++-13toolchain, whosebuiltin_include_directoriespointed at/usr/lib/gcc/{x86_64,aarch64}-linux-gnu/13— these no longer exist in the image. Linker flags also pulledlibstdc++_libbacktrace.a, which gcc-14 has folded intolibstdc++exp.a.This brings
release-0.7in line with the new CI image by cherry-picking the toolchain-relevant pieces frompp:b4f95e7af— full cherry-pick ofe207bf7bc(PR Fix Bazel c++ toolchain #282 "fix toolchain"): replace-l:libstdc++.awith-lstdc++(the explicit static-name flag is redundant under-static-libstdc++and breaks on libstdc++-14 in some setups).c29408fab— partial cherry-pick of3df13958d(PR Gcc 14 clang tidy 21 #271 "Gcc 14 clang tidy 21"), restricted to the gcc-14 toolchain switch:pp/MODULE.bazel: registercc_toolchain_for_g++-14_toolchain_{aarch64,x86_64}instead of theg++-13ones.pp/bazel/toolchain/BUILD: drop the now-unusedg++-13cc_toolchain_suite/cc_toolchain/toolchain/cc_toolchain_configentries (theg++-14definitions were already present on this branch).pp/bazel/toolchain/cc_toolchain_config.bzl: replace-lstdc++_libbacktracewith-lstdc++exp.pp/scripts/test_coredump.sh:--config=g++-13→--config=g++-14.What is intentionally NOT picked from PR #271
PR #271 in
ppis layered on top of PR #270 "GOST compile flags", which was never back-ported torelease-0.7. The following parts of #271 are therefore left out:Dockerfile.ci, all.github/workflows/*and the newcleanup_pr_images.yaml—release-0.7consumes the CI image built frompp, so no workflow changes are needed.pp/.clang-tidyand the bulk of test/source updates that come with the clang-tidy 19 → 21 upgrade and thebugprone-*diagnostics — those depend on the GOST flags and stricter warnings introduced by GOST compile flags #270.gost_flags/clang_tidyplumbing incc_toolchain_config.bzlandBUILD— same reason.The 3-way merge on
pp/bazel/toolchain/BUILDcorrectly dropped theclang_tidy = \":clang_tidy\"attribute that #271 added, because thecc_toolchain_configrule onrelease-0.7does not declare it.Test plan
cpp-testsworkflow (matrix:OPT={dbg,opt},SANITIZERS={no_sanitizers,with_sanitizers},arch={amd64,arm64}) — confirms the C++ unit tests build and pass under gcc-14 with the new toolchain config.build-go-bindingsworkflow (matrix:COMPILATION_MODE={dbg,opt},ASAN={false,true},arch={amd64,arm64}) — confirms cgo links cleanly with-lstdc++expand without-l:libstdc++.a.go-testsworkflow — confirms downstream Go tests still pass with the relinked C++ artifact.build_devjob (triggered automatically on PR) — confirms werfcpp-artifact(which uses the sametoolkitimage) still builds.If any step fails with new
-Werrorwarnings or a missing symbol that traces back togost_flags/libstdc++exp, that is the signal to either back-port the relevant slice of #270 or revert a specific flag here.Made with Cursor