I don't think this is a GCC bug except for the unitialized predicates is not working.  The reason why it fails for -Og is because jump threading is disabled as you want to be able to step through the code.  -O1 must not decided jump threading is profitable either.

For the unitialized predicates issue, it might be because switch statements are not handled.

FWIW I stumbled over what I believe is the same issue inside the boost v1.55.0 lexical_cast implementation.  That also only shows up as a "possible uninitialized" at -Og optimization only.  I can provide preprocessed source if necessary (though, being boost, it's 80k lines, ugh) but if you have gcc4.9.0 and boost 1.55 available:

$ cat test.cc
#include <boost/lexical_cast.hpp>

int test() { return boost::lexical_cast<int>("1"); }

$ g++ -Wall -Wextra -Og -c test.cc
test.cc: In function ‘int test()’:
test.cc:4:40: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
     return boost::lexical_cast<int>("1");


The relevant lines in boost itself appear to be http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0/boost/lexical_cast.hpp lines 2365-2377 where the "result" is optionally initialized.

I'll also submit this to the boost developers in case they have some ideas.

Created attachment 35384 [details]
Preprocessed source for boost::lexical_cast case

I can reproduce the same problem with Debian Jessie's gcc 4.9.2 and a self-compiled gcc 4.9.1 when compiling:

 #include <boost/lexical_cast.hpp>

 int wibble()
 {
     return boost::lexical_cast<int>("1");
 }

Preprocessed source attached (compressed to avoid file size limit.)

 $ g++ -Wall -Werror -Og -save-temps test.cpp
 test.cpp: In function ‘int wibble()’:
 test.cpp:5:40: error: ‘result’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      return boost::lexical_cast<int>("1");
                                        ^
 cc1plus: all warnings being treated as errors

Oddly the warning is not reported when the function is named "main"!

The test case in comment #3 shows the same problem in gcc-5-branch r222333.

(In reply to Thomas Schwinge from comment #0)
> It does seem appropriate to me for GCC not to do such tracking at low
> optimization levels, but then the uninitialized warning should also be
> disabled (which I assume is happening for -O0?) to avoid false positive
> warnings.

It doesn't work like that. The uninit pass sees the code as transformed by other optimization passes, thus what the uninit pass sees depends not on a particular level but on the passes enabled, their order and their effect on the given code. Higher levels do not always mean better uninit warnings, either. Nonetheless, it would be useful to identify which passes do more good than harm for uninit (probably VRP) and enable those at lower levels somehow or even in some limited form in the FEs.

Chiming in after having noticed this issue with GCC 5.4.0 20160609 on Linux MInt 18.1 with Boost 1.58.0 (using lexical_cast). Quite annoying...

The test case in comment #0 is not diagnosed anymore.  Bisection points to r240221 as the fix.  Ditto for attachment 35384 [details] from comment #3.  Let me add the one from attachment 31970 [details] to the test suite and resolve this as fixed.

The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:980b12cc81979e52f491bf0dfe961d30c07fe864

commit r11-7869-g980b12cc81979e52f491bf0dfe961d30c07fe864
Author: Martin Sebor <msebor@redhat.com>
Date:   Fri Mar 26 16:37:34 2021 -0600

    PR tree-optimization/59970 - Bogus -Wmaybe-uninitialized at low optimization levels
    
            PR tree-optimization/59970
            * gcc.dg/uninit-pr59970.c: New test.