[Bug c/64823] New: [5.0 Regression] false "may be used uninitialized"

[Bug c/64823] New: [5.0 Regression] false "may be used uninitialized"

[alserkli at inbox dot ru]

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

            Bug ID: 64823
           Summary: [5.0 Regression] false "may be used uninitialized"
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alserkli at inbox dot ru

Compilation of (GDB) 7.9.50.20150127-cvs with (GCC) 5.0.0 20150127 fails due to
false warning (gdb is compiled with -Werror). It was not a problem in GCC
4.7.2.

// a.c: simplified from the expansion of ALL_OBJSECTIONS in
gdb/gdb/symfile.c:unmap_overlay_command
struct os { struct o *o; };
struct o { struct o *next; struct os *se; };
void f(struct o *o){
  struct os *s;
  if(o) s = o->se;
  while(o && s == o->se){
    s++; // here `o' is non-zero and thus s is initialized
    s == o->se  // `?' is essential, `if' does not trigger the warning
      ? (o = o->next, o ? s = o->se : 0)
      : 0;
  }
}

$ gcc -O2 -Wall -Werror -c a.c
a.c: In function ‘f’:
a.c:8:6: error: ‘s’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
     s++; // here `o' is non-zero and thus s is initialized
      ^
cc1: all warnings being treated as errors
>From gcc-bugs-return-475130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 27 17:54:21 2015
Return-Path: <gcc-bugs-return-475130-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15820 invoked by alias); 27 Jan 2015 17:54:20 -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 15642 invoked by uid 48); 27 Jan 2015 17:54:15 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/64771] [4.9/5 Regression] ICE(segfault) when passing coarrays around; ICE in gfc_zero_size_array in arith.c:1637
Date: Tue, 27 Jan 2015 17:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64771-4-A6NSPUwnvJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64771-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64771-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: 2015-01/txt/msg03124.txt.bz2
Content-length: 181

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd771

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
*** Bug 64355 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/64823] [5.0 Regression] false "may be used uninitialized", missed jump threading

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.9.2
           Keywords|                            |diagnostic,
                   |                            |missed-optimization
   Last reconfirmed|                            |2015-01-28
          Component|c                           |tree-optimization
                 CC|                            |law at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|[5.0 Regression] false "may |[5.0 Regression] false "may
                   |be used uninitialized"      |be used uninitialized",
                   |                            |missed jump threading
   Target Milestone|---                         |5.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue is we apply loop header copying here and correctly don't warn
about
the first loop body but figure the 2nd iteration is guarded with
effectively o->next != NULL which isn't the same predicate s was initialized
under.

This is also a missed jump-threading:

  <bb 2>:
  if (o_4(D) != 0B)
    goto <bb 3>;
  else
    goto <bb 15>;

  <bb 15>:
  goto <bb 4>;

  <bb 3>:
  s_7 = o_4(D)->se;

  <bb 4>:
  # s_16 = PHI <s_7(3), s_5(D)(15)>
  goto <bb 9>;

...

  <bb 9>:
  # o_10 = PHI <o_4(D)(4), o_11(8)>
  # s_13 = PHI <s_16(4), s_2(8)>
  if (o_10 != 0B)
    goto <bb 10>;
  else
    goto <bb 13>;

...

  <bb 13>:
  return;


Jeff - is DOM not able to see that?  The threading is in the loop header
but threads to the exit (that is, I'd thread the o_4(D) == 0 case to bb 13).
Looks like 4.9 does that in DOM1 already.

[Bug tree-optimization/64823] [5.0 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

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

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
Seems like something DOM ought to discover.  It's certainly possible that it's
discovered, but then discarded.  I'll take a look.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
*Very* likely a duplicate of 61409 based on some initial investigations. 
Obviously I'll verify that as I pull together a fix for this issue.

*** This bug has been marked as a duplicate of bug 61409 ***

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|DUPLICATE                   |---

--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
Actually not a duplicate now that I've been able to look deeper.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |law at redhat dot com

--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
So there's a few issues in play.  But the major issue is we have forwarder
blocks which are not eliminated because we "Protect loop headers" (see
tree-cfgcleanup.c).

Those forwarder blocks might have PHIs, but no statements.  The most
interesting threading opportunity in this case is threading to the loop exit
and thus completely bypassing the loop on some paths.

The code to prune the search space for jump threads pruned out those blocks. 
That's a bit too aggressive as evidenced by this BZ.  It's pretty easy to
detect these and special case them.

Second, we did not distinguish between a block with no statements and a block
where we did not process every statement.  So a block with no statements was
interpreted as a partially processed block and thus not suitable for being a
joiner block in a jump threading path.

With those two fixed, we find the missed jump thread & bypass the loop when
reached via the o == 0 path out of the first conditional.  That in turn allows
the compiler to recognize that within the loop "s" is always initialized

Patch in testing.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Feb 13 21:09:58 2015
New Revision: 220696

URL: https://gcc.gnu.org/viewcvs?rev=220696&root=gcc&view=rev
Log:
    PR tree-optimization/64823
    * tree-vrp.c (identify_jump_threads): Handle blocks with no statements.
    * tree-ssa-threadedge.c (potentially_threadable_block): Allow
    threading through blocks with PHIs, but no statements.
    (thread_through_normal_block): Distinguish between blocks where
    we did not process all the statements and blocks with no statements.

    PR tree-optimization/64823
    gcc.dg/uninit-20.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/uninit-20.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-threadedge.c
    trunk/gcc/tree-vrp.c

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

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

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
Fixed jump threader to handle case exposed by this BZ, which in turn fixes the
false positive "may be used uninitialized" warning.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Patch reverted due to bootstrap comparison failure using non-default configure
flags.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[law at redhat dot com]

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

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

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Fixed again after addressing bootstrap failure HJ experienced.

[Bug tree-optimization/64823] [5 Regression] false "may be used uninitialized", missed jump threading

[alserkli at inbox dot ru]

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

Alexander Klimov <alserkli at inbox dot ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |VERIFIED

--- Comment #11 from Alexander Klimov <alserkli at inbox dot ru> ---
GDB can now be build with GCC 5.0.0 20150217 even if the GDB patch is undone:

--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -3441,7 +3441,7 @@ static void
 unmap_overlay_command (char *args, int from_tty)
 {
   struct objfile *objfile;
-  struct obj_section *sec = NULL;
+  struct obj_section *sec;

   if (!overlay_debugging)
     error (_("Overlay debugging not enabled.  "