fix: add -Wmaybe-uninitialized pragma to union storage constructors#145
Conversation
GCC 7+ produces false-positive -Wmaybe-uninitialized warnings at -O3 when deeply inlining through union constructors that initialize one member while another (dummy_) exists. This is the same class of false positive addressed in boostorg/variant2#55. The pragmas are placed around the forwarding constructors in both constexpr_union_storage_t and fallback_union_storage_t.
f6bcfaa to
88e2378
Compare
|
Complementing the PR for future reference: In most cases, Boost.URL builds cleanly with GCC 15 at CI run without the Boost.Optional patch (showing the errors): https://github.com/boostorg/url/actions/runs/22404543043/job/64860913382?pr=981 CI run with the patch (all green): https://github.com/boostorg/url/actions/runs/22371586620 Why this is a false positiveThe warning is about variant2's internal storage member Here's the chain:
Whose "fault" is it?The root cause is variant2's nested union storage being opaque to GCC's optimizer. But GCC reports This is the same pattern we hit in Boost.URL itself: variant2 was the "cause", but GCC blamed our Why
|
GCC 7+ at
-O3produces false-positive-Wmaybe-uninitializedwarnings when inlining through theconstexpr_union_storage_tandfallback_union_storage_tconstructors. Same class of false positive as boostorg/variant2#55 — union with a dummy and value member, constructor initializes value.Adds scoped pragmas around both forwarding constructors in
union_optional.hpp.Refs boostorg/url#981