Skip to content

Conversation

@vinniefalco
Copy link
Member

No description provided.

@pdimov
Copy link
Member

pdimov commented Dec 31, 2025

This test doesn't emit any warnings under GCC 12+ in CI.

@vinniefalco vinniefalco force-pushed the develop branch 2 times, most recently from c847bce to 486c62e Compare December 31, 2025 14:17
@vinniefalco
Copy link
Member Author

Yes I'm trying to figure out how to reproduce it reliably. It might be the build settings?

@pdimov
Copy link
Member

pdimov commented Dec 31, 2025

No, it's the test code. It's hard to trigger the warning; you need just the right amount of complexity and a lot of luck. That's because the warning only fires when the optimizer can see that the exception_ptr is uninitialized, but cannot see that index() is 0. And usually, it either sees both of these things, or none of them.

@pdimov
Copy link
Member

pdimov commented Dec 31, 2025

It's probably going to be easier to reproduce this by using system::result than variant directly, as it adds a layer of complexity.

@vinniefalco vinniefalco force-pushed the develop branch 2 times, most recently from 0d672fb to f910467 Compare December 31, 2025 15:47
Add variant_gcc_false_positive.cpp to reproduce GCC 12+ spurious
-Wmaybe-uninitialized warnings when copying/moving variant containing
non-trivially-copyable types like std::exception_ptr and std::string.

Tests use boost::system::result which internally uses variant2, and
include coroutine-based tests when C++20 coroutine support is available.

The test uses -O3 optimization to trigger the aggressive inlining that
exposes the false positive where GCC's dataflow analysis cannot prove
the discriminator ensures only initialized alternatives are accessed.

See boostorg#33
Add diagnostic pragmas to suppress spurious -Wmaybe-uninitialized
warnings in GCC 12+ when copying/moving variant with non-trivially
copyable types like std::exception_ptr.

GCC 12+'s improved dataflow analysis sees code paths for all
alternatives via mp_with_index and warns that members may be
uninitialized, even though the variant's discriminator guarantees
only the active alternative is accessed.

The workaround can be disabled by defining BOOST_VARIANT2_GCC12_WORKAROUND
to 0 before including the header.

Fixes boostorg#33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants