[Bug c++/58455] New: spurious "may be used uninitialized" warning with -Og

[Bug c++/58455] New: spurious "may be used uninitialized" warning with -Og

[rbd at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

            Bug ID: 58455
           Summary: spurious "may be used uninitialized" warning with -Og
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rbd at debian dot org

(My gcc 4.8 is new enough that it has the fix for PR middle-end/58377)

I have a case of C++ code that spuriously warns about a "may be used
uninitialized" variable.  I haven't been able to turn this into similar C code
that still warns.  Also the "|| false" in the if statement seems to do
something -- without it I don't get the warning!

$ cat y.cpp
struct B
{
    int offset;
    bool is_loaded(unsigned char *p1)
    {
        if (offset) {
            *p1 = offset;
            return true;
        }
        return false;
    }
};

unsigned char match(struct B ref)
{
        unsigned char ref_offset;
        if (!ref.is_loaded(&ref_offset) || false)
                return ref_offset;
        else
                return 0;
}


$ gcc -v -Wall -Og -Werror -c ~/y.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu3) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Og' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE /home/roland/y.cpp -mtune=generic -march=x86-64
-Wall -Werror -Og -fstack-protector -Wformat -Wformat-security
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.8
 /usr/include/x86_64-linux-gnu/c++/4.8
 /usr/include/c++/4.8/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Og' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu3) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Og' '-Werror' '-c' '-o'
'/home/roland/.ccache/a/4/3eaed08e6d4177435e048912941826-3578.o.tmp.roland-t410s.22760'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -fpreprocessed
/home/roland/.ccache/tmp/y.tmp.roland-t410s.22760.ii -quiet -dumpbase
y.tmp.roland-t410s.22760.ii -mtune=generic -march=x86-64 -auxbase-strip
/home/roland/.ccache/a/4/3eaed08e6d4177435e048912941826-3578.o.tmp.roland-t410s.22760
-Og -Wall -Werror -version -fstack-protector -Wformat -Wformat-security -o
/tmp/cc6olJBS.s
GNU C++ (Ubuntu/Linaro 4.8.1-10ubuntu3) version 4.8.1 (x86_64-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.8.1-10ubuntu3) version 4.8.1 (x86_64-linux-gnu)
    compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9d410e3e527a5e0f1d5bb684c93d46d6
/home/roland/y.cpp: In function ‘unsigned char match(B)’:
/home/roland/y.cpp:16:23: error: ‘ref_offset’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
         unsigned char ref_offset;
                       ^
cc1plus: all warnings being treated as errors


$ for o in Og O0 O1 O2 O3; do echo == $o ==;  gcc -Wall -$o -Werror -c ~/y.cpp;
done
== Og ==
/home/roland/y.cpp: In function ‘unsigned char match(B)’:
/home/roland/y.cpp:16:23: error: ‘ref_offset’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
         unsigned char ref_offset;
                       ^
cc1plus: all warnings being treated as errors
== O0 ==
== O1 ==
== O2 ==
== O3 ==
>From gcc-bugs-return-430054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 18 06:45:40 2013
Return-Path: <gcc-bugs-return-430054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10542 invoked by alias); 18 Sep 2013 06:45:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10490 invoked by uid 48); 18 Sep 2013 06:45:36 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58455] spurious "may be used uninitialized" warning with -Og
Date: Wed, 18 Sep 2013 06:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58455-4-81pKxKb5Zi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58455-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58455-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-09/txt/msg01294.txt.bz2
Content-length: 529

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX455

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why do you think this is spurious?  You are returning ref_offset if is_loaded
method returns false, i.e. exactly when ref_offset hasn't been initialized.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[rbd at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

--- Comment #2 from Roland Dreier <rbd at debian dot org> ---
Arg, I don't seem to be able to avoid breaking my test cases while minimizing
them.  So for my first test case here the issue seems to be that -Og is the
only level that *correctly* warns, which is surprising and I guess is a bug in
it's own right!

Sorry for the confusion.

However the test case I was originally working with and then broke is the
following:

$ cat y.cpp
struct B
{
    int offset;
    bool is_loaded(unsigned char *p1)
    {
        if (offset) {
            *p1 = offset;
            return true;
        }
        return false;
    }
};

unsigned char match(struct B ref)
{
        do {
                unsigned char ref_offset;
                if (!ref.is_loaded(&ref_offset) || false)
                        continue;
                return ref_offset;
        } while (false);

        return 0;
}


$ for o in Og O0 O1 O2 O3; do echo == $o ==;  gcc -Wall -$o -Werror -c ~/y.cpp;
done
== Og ==
/home/roland/y.cpp: In function ‘unsigned char match(B)’:
/home/roland/y.cpp:17:31: error: ‘ref_offset’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
                 unsigned char ref_offset;
                               ^
cc1plus: all warnings being treated as errors
== O0 ==
== O1 ==
== O2 ==
== O3 ==


in that case is_loaded returns true when it sets the pointer; if it returns
false we continue, fall out of the loop and don't touch the pointer value.  So
I'm pretty sure this case is correctly classified as spurious.
>From gcc-bugs-return-430056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 18 07:17:49 2013
Return-Path: <gcc-bugs-return-430056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1059 invoked by alias); 18 Sep 2013 07:17:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 994 invoked by uid 48); 18 Sep 2013 07:17:45 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found
Date: Wed, 18 Sep 2013 07:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-58332-4-J1Jo8ZZEXy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58332-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58332-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-09/txt/msg01296.txt.bz2
Content-length: 421

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX332

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Fixed.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-18
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Roland Dreier from comment #2)
> Arg, I don't seem to be able to avoid breaking my test cases while
> minimizing them.  So for my first test case here the issue seems to be that
> -Og is the only level that *correctly* warns, which is surprising and I
> guess is a bug in it's own right!
> 
> Sorry for the confusion.
> 
> However the test case I was originally working with and then broke is the
> following:
> 
> $ cat y.cpp
> struct B
> {
>     int offset;
>     bool is_loaded(unsigned char *p1)
>     {
>         if (offset) {
>             *p1 = offset;
>             return true;
>         }
>         return false;
>     }
> };
> 
> unsigned char match(struct B ref)
> {
>         do {
>                 unsigned char ref_offset;
>                 if (!ref.is_loaded(&ref_offset) || false)
>                         continue;
>                 return ref_offset;
>         } while (false);
> 
>         return 0;
> }
> 
> 
> $ for o in Og O0 O1 O2 O3; do echo == $o ==;  gcc -Wall -$o -Werror -c
> ~/y.cpp; done
> == Og ==
> /home/roland/y.cpp: In function ‘unsigned char match(B)’:
> /home/roland/y.cpp:17:31: error: ‘ref_offset’ may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
>                  unsigned char ref_offset;
>                                ^
> cc1plus: all warnings being treated as errors
> == O0 ==
> == O1 ==
> == O2 ==
> == O3 ==
> 
> 
> in that case is_loaded returns true when it sets the pointer; if it returns
> false we continue, fall out of the loop and don't touch the pointer value. 
> So I'm pretty sure this case is correctly classified as spurious.

Confirmed.  -Og misses a simple jump-threading to un-confuse the CFG here:

  <bb 2>:
  _7 = ref.offset;
  if (_7 != 0)
    goto <bb 3>;
  else
    goto <bb 4>;

  <bb 3>:
  ref_offset_8 = (unsigned char) _7;

  <bb 4>:
  # _9 = PHI <0(2), 1(3)>
  # ref_offset_6 = PHI <ref_offset_5(D)(2), ref_offset_8(3)>
  if (_9 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

  <bb 5>:

  <bb 6>:
  # iftmp.1_1 = PHI <1(4), 0(5)>
  if (iftmp.1_1 != 0)
    goto <bb 8>;
  else
    goto <bb 7>;

  <bb 7>:

  <bb 8>:
  # _2 = PHI <ref_offset_6(7), 0(6)>
  return _2;

which is caused by not folding the || false and gimplifying it to

        D.2218 = B::is_loaded (&ref, &ref_offset);
        D.2219 = ~D.2218;
        if (D.2219 != 0) goto <D.2215>; else goto <D.2220>;
        <D.2220>:
        if (0 != 0) goto <D.2215>; else goto <D.2216>;
        <D.2215>:
        iftmp.1 = 1;
        goto <D.2217>;
        <D.2216>:
        iftmp.1 = 0;
        <D.2217>:
        retval.0 = iftmp.1;
        if (retval.0 != 0) goto <D.2221>; else goto <D.2222>;
        <D.2221>:
        goto <D.2211>;
        <D.2222>:
        D.2223 = ref_offset;
        return D.2223;

After early CCP we then alreay have the final

  <bb 7>:
  # iftmp.1_1 = PHI <1(5), 0(6)>
  retval.0_10 = iftmp.1_1;
  if (retval.0_10 != 0)
    goto <bb 9>;
  else
    goto <bb 8>;

  <bb 8>:
  ref_offset_11 = ref_offset_13;
  goto <bb 10>;

  <bb 9>:
  _14 = 0;

patterns.  With -O1+ phiopt merges those blocks.  IMHO this asks for
moving/adding phiopt in early optimizations.  phiopt needs copyproped
IL, so the natural place is to add it after a copyprop pass (relying
on copyprops simple DCE to clean out empty forwarder blocks and CFG cleanup
for removing them).
>From gcc-bugs-return-430062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Sep 18 08:17:15 2013
Return-Path: <gcc-bugs-return-430062-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27642 invoked by alias); 18 Sep 2013 08:17:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 27614 invoked by uid 48); 18 Sep 2013 08:17:12 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/58451] ICE with segfault at -O3 on x86_64-linux-gnu (both 32-bit and 64-bit modes)
Date: Wed, 18 Sep 2013 08:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-58451-4-CL2vfLbyc3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58451-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58451-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-09/txt/msg01302.txt.bz2
Content-length: 541

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX451

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be already fixed by richi's r202644.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.  Adding a phiopt pass isn't enough to fix this as we still end up with

  <bb 4>:
  # _9 = PHI <0(2), 1(3)>
  # ref_offset_6 = PHI <ref_offset_5(D)(2), ref_offset_8(3)>
  _10 = ~_9;
  if (_10 != 0)
    goto <bb 6>;
  else
    goto <bb 5>;

  <bb 5>:

  <bb 6>:
  # _2 = PHI <ref_offset_6(5), 0(4)>

where -O1 needs DOM to thread the two jumps out of bb 4 and phicprop
to clean up the result.

But at -Og we definitely do not want to perform jump threading.  During
gimplification we are confused by the condition being wrapped inside
a CLEANUP_POINT and thus gimplify_cond_expr does not break apart && and ||.
So it looks like gimplification could only handle the || 0 specially,
but that looks like a hack.

While for code quality a simple phiopt pass might make sense for debugging
it would be better to generate improved initial code for the sequence.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Which means - don't hold your breath ;)  This one isn't easy to fix without
sacrifying what -Og is supposed to provide.

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 30848
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30848&action=edit
phiopt pass for -Og

[Bug c++/58455] spurious "may be used uninitialized" warning with -Og

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
             Blocks|                            |19794

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
I've long pondered separating jump threading from DOM and making jump threading
a backwards walk of the use-def chains from the condition.

Given such a structure one could envision a knob which controlled how far back
in the use-def chains we walk.  If that knob just allowed walking one
statement, we'd catch the jump threads in blocks #4 and #7 trivially.

But that's all work far into the future.

Of course that still leaves an open question about what, if any threading we'd
want to do at -Og.  We'd certainly have to look at that closely.