Boost C++ Libraries: Ticket #12513: Boost optional (1.60/1.61/1.62) generates "may be used uninitialized" warnings with gcc 6

attachment set

romain.geissler@… — Mon, 10 Oct 2016 21:59:18 GMT

attachment → test.cpp

test.cpp

akrzemi1 — Tue, 14 Feb 2017 12:43:53 GMT

I changed your example, so that it compiles. I tested it with G++ 6.2, -std=gnu++14 -Wall -Wextra -O2, and it compiles without any warning:

http://melpon.org/wandbox/permlink/lLRX9m54qfF9jt8D

Can you confirm?

anonymous — Tue, 14 Feb 2017 13:12:29 GMT

Hi,

What you did is simply inline what "useA" and "getAnOptional" do, in which case gcc doesn't propagate inline code the same way and doesn't reach the same conclusion about maybe uninitialized warnings. While that would be OK for some project, the way we work in my company inlining code may cause us more trouble since it would require rebuilding many libraries that we currently can't afford to rebuild each time we change the code.

It appears clear now that it is a gcc bug. Maybe we should try if adding GCC specific pragmas directly in boost to try to silence them. Currently I am using pragma in my own proprietary code to silence it, but it would be better if it would be possible in boost.

Unfortunately gcc 6.3 and the current gcc 7 trunk is still bogus...

Anyway, since it's a gcc bug, we might just close this boost issue if work it around in Boost is too complex.

Cheers, Romain

akrzemi1 — Tue, 14 Feb 2017 14:19:46 GMT

Romain, I can see that you have created a GCC bug report for this quite a while ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044 From the discussion therein, I can see that -Wmaybe-uninitialized is by its nature prone to false positives.

Also, there might be no place to put the #pragmas, because the warning is reported for the inlined, optimized code.

Also, before we close this, can you check if the workaround described here http://www.boost.org/doc/libs/1_63_0/libs/optional/doc/html/boost_optional/tutorial/gotchas/false_positive_with__wmaybe_uninitialized.html

silences the warnings for you?

romain.geissler@… — Tue, 14 Feb 2017 14:27:37 GMT

Back then I already tried many different ways to rewrite my own code to silence the warning, including what is documented in Boost, but none of them worked. Thus I had to rely in using pragmas in my code.

The only attempt to "fix" this on Boost I found so far is the pull request a sent you a while ago, but as you, I don't like the fact that it comes at the cost of performances. I had little time to try to find another solution since then.

In 2017 I plan to move the code base of my company to C++17 and use std::optional rather than boost::optional (which does not have the issue).

If I am the only one complaining about that, I think this ticket can be closed.

akrzemi1 — Tue, 14 Feb 2017 14:31:37 GMT

You are not. This has came back many a time. I think I know how to fix that, but I am really short of time. This problem occurs only for boost::optional instantiated with scalar types (right?) The plan is to provide a specialization for trivial types that would render a trivially-copyable optional.

akrzemi1 — Tue, 14 Feb 2017 22:44:39 GMT

Ok, I reproduced your warning: http://melpon.org/wandbox/permlink/HKubpdDe7A52Ouql

But I note that the warning disappears, when I apply the workaround from the docs:

http://melpon.org/wandbox/permlink/M73b1cqYt5g9qC8E