https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733

            Bug ID: 89733
           Summary: [7/8/9 Regression] False positive -Wuninitialized in
                    C++14+ mode
           Product: gcc
           Version: 9.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: regression
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nok.raven at gmail dot com
  Target Milestone: ---
              Host: x86_64
            Target: x86_64

Hello,

The -Wuninitialized warning comes from one of Boost.Spirit tests in C++14+ mode
with GCC 7/8/9. GCC's ASan and UBSan does not detect violations. Clang's
-Wuninitialized and sanitizers also report nothing.

I have double checked the things, the member
(https://github.com/boostorg/spirit/blob/ae49b5c3d15d9105ce4d0f10378c7693dcaa5ae6/include/boost/spirit/home/lex/lexer/lexertl/functor_data.hpp#L400)
is not explicitly initialized in the class constructor (with explicit
initialization the warning is gone), but it is not accessed before an
assignment (checked by wrapping the value type with a boost::optional and
replacing reads to .value(), warning is already gone with the change).

I am sorry I do not have a minimal repro. Every time I try to reduce the test,
the warning either turns into -Wmaybe-uninitialized or is gone. The shortest
one I got is https://wandbox.org/permlink/yTLyG6C6arXfFlJz

```
#include <boost/spirit/include/lex_lexertl.hpp>
#include <boost/spirit/include/qi_parse.hpp>
#include <boost/spirit/include/qi_rule.hpp>

namespace lex = boost::spirit::lex;
namespace qi = boost::spirit::qi;
namespace mpl = boost::mpl;

typedef lex::lexertl::token<char const*, mpl::vector<int> > token_type;
typedef lex::lexertl::actor_lexer<token_type> lexer_type;
typedef lex::lexer<lexer_type>::iterator_type iterator_type;

int main()
{
    char const* s     = "123.";
    char const* first = s;
    char const* last  = s + std::strlen(s);

    lex::lexer<lexer_type> lexer;
    lex::token_def<int> integer; integer = "[0-9]+"; lexer.self += integer;
    qi::rule<iterator_type> grammar = integer;

    lex::tokenize_and_parse(first, last, lexer, grammar);
}
```

$ g++ -O1 -std=c++14 repro.cpp -I. -Werror=uninitialized
In file included from ./boost/spirit/home/lex/lexer/lexertl/lexer.hpp:22,
                 from ./boost/spirit/home/lex/lexer_lexertl.hpp:16,
                 from ./boost/spirit/include/lex_lexertl.hpp:16,
                 from repro.cpp:1:
./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp: In function 'bool
boost::spirit::lex::tokenize_and_parse(Iterator&, Iterator, const Lexer&, const
ParserExpr&) [with Iterator = const char*; Lexer =
boost::spirit::lex::lexer<boost::spirit::lex::lexertl::actor_lexer<boost::spirit::lex::lexertl::token<const
char*, boost::mpl::vector<int> > > >; ParserExpr =
boost::spirit::qi::rule<boost::spirit::lex::lexertl::iterator<boost::spirit::lex::lexertl::functor<boost::spirit::lex::lexertl::token<const
char*, boost::mpl::vector<int> >, boost::spirit::lex::lexertl::detail::data,
const char*, mpl_::bool_<true>, mpl_::bool_<true> > > >]':
./boost/spirit/home/lex/lexer/lexertl/functor_data.hpp:276:15: error:
'<anonymous>.boost::spirit::lex::lexertl::detail::data<const char*,
mpl_::bool_<true>, mpl_::bool_<true>,
boost::variant<boost::detail::variant::over_sequence<boost::mpl::l_item<mpl_::long_<2>,
boost::iterator_range<const char*>, boost::mpl::l_item<mpl_::long_<1>, int,
boost::mpl::l_end> > > > >::end_' is used uninitialized in this function
[-Werror=uninitialized]
         class data<Iterator, mpl::true_, HasState, TokenValue>
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For a full test: Download Boost 1.69, unpack it, invoke

cd boost_1_69_0
./bootstrap
./b2 headers
g++ -O1 -std=c++14 libs/spirit/test/lex/regression_syntax_error.cpp -I.
-Werror=uninitialized


PS: There are bunch of -Wmaybe-uninitialized warnings related to
boost::optional usage in other tests on master (Boost 1.70 Beta) that also
seems to be false positives.

Reply via email to