[Bug c/61409] New: [4.9 regression] -Wmaybe-uninitialized false-positive with -O2

[Bug c/61409] New: [4.9 regression] -Wmaybe-uninitialized false-positive with -O2

[eggert at gnu dot org]

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

            Bug ID: 61409
           Summary: [4.9 regression] -Wmaybe-uninitialized false-positive
                    with -O2
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eggert at gnu dot org

Created attachment 32887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32887&action=edit
sample program illustrating the false positive

GCC 4.9.0 x86-64.  I do not observe the bug with GCC 4.8.2.

I discovered this bug when compiling GNU Emacs, and abstracted it into the
simplest test case I could easily generate.  When I compile the attached
program g.i with the command:

gcc -Wmaybe-uninitialized -O2 -c g.i

GCC warns:

g.i:607:21: warning: 'mw' may be used uninitialized in this function
[-Wmaybe-uninitialized]
       mw->pixel_top = rw->pixel_height;

But mw cannot possibly be uninitialized here.  Also, mw was used in the
previous line, with no warning.

The bug may be related to lines 602 and 603, which are long and which do not
mention mw, as removing these lines makes the diagnostic go away.

[Bug c/61409] [4.9 regression] -Wmaybe-uninitialized false-positive with -O2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32887|0                           |1
        is obsolete|                            |
                 CC|                            |manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 32888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32888&action=edit
reduced testcase

It also fails on trunk.

Hum, the testcase is a bit large. It should be possible to remove at least some
struct members and enums which seem irrelevant. I removed quite a few lines but
I'm sure with some patience the testcase could be reduced to 20 lines or so.

My guess is that what is uninitialized is "rw" and some optimization pass
messed up the variable names when creating temporaries.
>From gcc-bugs-return-453181-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 09:35:19 2014
Return-Path: <gcc-bugs-return-453181-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3287 invoked by alias); 4 Jun 2014 09:35:19 -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 3253 invoked by uid 48); 4 Jun 2014 09:35:15 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61410] strcat overwrites destination string when compiling with optimizations
Date: Wed, 04 Jun 2014 09:35: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.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse 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: component
Message-ID: <bug-61410-4-o921JKzvcr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61410-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61410-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: 2014-06/txt/msg00263.txt.bz2
Content-length: 505

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
This seems already fixed in 4.8 (there is probably a dup somewhere), and I
believe it is too late for the last release of the 4.7 branch.

[Bug c/61409] [4.9 regression] -Wmaybe-uninitialized false-positive with -O2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32888|0                           |1
        is obsolete|                            |

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 32889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32889&action=edit
even more reduced

This could be even further reduced
>From gcc-bugs-return-453184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 10:00:56 2014
Return-Path: <gcc-bugs-return-453184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24517 invoked by alias); 4 Jun 2014 10:00:55 -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 24493 invoked by uid 48); 4 Jun 2014 10:00:52 -0000
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61405] Not emitting "enumeration value not handled in switch" warning for bit-field enums
Date: Wed, 04 Jun 2014 10:00: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: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jamborm 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: bug_status resolution
Message-ID: <bug-61405-4-H5MIC2g94F@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61405-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61405-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: 2014-06/txt/msg00266.txt.bz2
Content-length: 489

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida405
Bug 61405 depends on bug 61340, which changed state.

Bug 61340 Summary: ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida340

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

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
   Target Milestone|---                         |4.9.1
            Summary|[4.9 regression]            |[4.9/4.10 regression]
                   |-Wmaybe-uninitialized       |-Wmaybe-uninitialized
                   |false-positive with -O2     |false-positive with -O2

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[eggert at gnu dot org]

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

--- Comment #3 from Paul Eggert <eggert at gnu dot org> ---
(In reply to Manuel López-Ibáñez from comment #1)

> My guess is that what is uninitialized is "rw" and some optimization pass
> messed up the variable names when creating temporaries.

I'm afraid it's more serious than that, because 'rw = XWINDOW (make_window
());' always initializes 'rw'.

Thanks for simplifying the test case.
>From gcc-bugs-return-453211-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 15:30:55 2014
Return-Path: <gcc-bugs-return-453211-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16130 invoked by alias); 4 Jun 2014 15:30:55 -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 16104 invoked by uid 48); 4 Jun 2014 15:30:51 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61412] Warnings incorrectly suppressed when compiling previously preprocessed file
Date: Wed, 04 Jun 2014 15:30: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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:
Message-ID: <bug-61412-4-c0xplwJaWm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61412-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: 2014-06/txt/msg00293.txt.bz2
Content-length: 214

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm pretty sure there's an existing report about this.

Adding -Wsystem-headers makes it warn.

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-04
                 CC|                            |davidxl at gcc dot gnu.org
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paul Eggert from comment #3)
> (In reply to Manuel López-Ibáñez from comment #1)
>  
> > My guess is that what is uninitialized is "rw" and some optimization pass
> > messed up the variable names when creating temporaries.
> 
> I'm afraid it's more serious than that, because 'rw = XWINDOW (make_window
> ());' always initializes 'rw'.

Yes you're right. Simplifying further we get:


extern long int make_window (void);
struct vectorlike_header  {  long int size;  };

static  _Bool
PSEUDOVECTORP (long int a)
{
  if (! (((int) a & ~0) == 5))
    return 0;
  else
    {
      struct vectorlike_header *h = (void *) a - 5;
      return (h->size == 4611686018595160064);

    }
}
struct window
  {
    int line_height;
    int pixel_width;
    int pixel_height;
    int column_width;
    int text_cols;
    int internal_border_width;
    int left_fringe_width, right_fringe_width;
};


struct window *
make_frame (_Bool mini_p)
{
  struct window *rw, *mw;
  rw = (struct window *) make_window ();
  if (mini_p)
    {
      long int a = make_window ();
      if (!PSEUDOVECTORP (a)) return rw;
      mw  = (void*) a - 5;
    }
  rw->pixel_width = ((rw->text_cols * (rw->column_width))
                     + (rw->left_fringe_width + (rw->right_fringe_width)) + 2 *
(rw->internal_border_width));
  rw->pixel_height = ((rw->text_cols * (rw->line_height)));
  if (mini_p)
    {
      mw->pixel_height = rw->pixel_height;
    }
  return rw;
}


For this, the uninit pass reports:
[WORKLIST]: add to initial list: mw_1 = PHI <mw_9(D)(9), mw_34(12)>
[CHECK]: examining phi: mw_1 = PHI <mw_9(D)(9), mw_34(12)>

[CHECK] Found def edge 1 in mw_1 = PHI <mw_9(D)(9), mw_34(12)>
[BEFORE SIMPLICATION -- [USE]:
mw_1->pixel_height = _28;
is guarded by :

mini_p_8(D) != 0


[BEFORE NORMALIZATION --[USE]:
mw_1->pixel_height = _28;
is guarded by :

mini_p_8(D) != 0


[AFTER NORMALIZATION -- [USE]:
mw_1->pixel_height = _28;
is guarded by :

mini_p_8(D) != 0


[BEFORE SIMPLICATION -- [DEF]:
mw_1 = PHI <mw_9(D)(9), mw_34(12)>
is guarded by :

mini_p_8(D) != 0 (.AND.)  (.NOT.) _31 != 5 (.AND.) _35 == 4611686018595160064


[BEFORE NORMALIZATION --[DEF]:
mw_1 = PHI <mw_9(D)(9), mw_34(12)>
is guarded by :

mini_p_8(D) != 0 (.AND.)  (.NOT.) _31 != 5 (.AND.) _35 == 4611686018595160064


[AFTER NORMALIZATION -- [DEF]:
mw_1 = PHI <mw_9(D)(9), mw_34(12)>
is guarded by :

_35 == 4611686018595160064 (.AND.)  (.NOT.) _31 != 5 (.AND.) mini_p_8(D) != 0


[CHECK]: Found unguarded use: mw_1->pixel_height = _28;

It seems the computation of the logical guards cannot figure out that if (_35
== 4611686018595160064 (.AND.)  (.NOT.) _31 != 5) is false then the function
terminates and there cannot be uninitialized uses. From the GIMPLE output, it
does not look as if it trivial to know this.
>From gcc-bugs-return-453221-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 16:03:33 2014
Return-Path: <gcc-bugs-return-453221-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23398 invoked by alias); 4 Jun 2014 16:03:32 -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 23368 invoked by uid 48); 4 Jun 2014 16:03:29 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2
Date: Wed, 04 Jun 2014 16:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61409-4-qB8eaCyARh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61409-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61409-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00303.txt.bz2
Content-length: 349

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

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paul Eggert from comment #0)
> Also, mw was used in the
> previous line, with no warning.

I think uinit uses are computed walking the CFG backwards, and only one use is
reported per variable.
>From gcc-bugs-return-453222-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 16:15:16 2014
Return-Path: <gcc-bugs-return-453222-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30116 invoked by alias); 4 Jun 2014 16:15: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 30051 invoked by uid 48); 4 Jun 2014 16:15:08 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61412] Warnings incorrectly suppressed when compiling previously preprocessed file
Date: Wed, 04 Jun 2014 16:15: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu 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-61412-4-MZLQmmZwks@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00304.txt.bz2
Content-length: 1228

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Matt Godbolt from comment #5)
> 
> That 250K+ file also exhibits the problem: that is, the warning is
> suppressed even within the main body of the file. I then whittled down the
> preprocessed file to just those two lines. In the original file the "# ..."
> line came from the middle of a macro expansion defined by a header included
> via an -isystem path. The filename in the "# " line refers to the C++ file
> though in both cases.

Sorry, this is a bit confusing.

The line in question comes before preprocessing from which file? Is this file
marked as a system-header? If yes, then why do you expect to get a warning
without -Wsystem-headers? If not, did you edit the processed file? Could we get
the processed file without editing (or at least without removing any
line-markers)?
>From gcc-bugs-return-453223-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 16:19:57 2014
Return-Path: <gcc-bugs-return-453223-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32113 invoked by alias); 4 Jun 2014 16:19:57 -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 32075 invoked by uid 48); 4 Jun 2014 16:19:53 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61412] Warnings incorrectly suppressed when compiling previously preprocessed file
Date: Wed, 04 Jun 2014 16:19: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu 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:
Message-ID: <bug-61412-4-RLC4yH5KUv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00305.txt.bz2
Content-length: 405

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #6)
> May be a dup of bug 57201.

I think not: that one is about warnings appearing after preprocessing (and we
know why this happens). This one is about warnings disappearing (and we do not
know yet why this happens).
>From gcc-bugs-return-453224-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 16:23:30 2014
Return-Path: <gcc-bugs-return-453224-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7238 invoked by alias); 4 Jun 2014 16:23:30 -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 7214 invoked by uid 48); 4 Jun 2014 16:23:27 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61412] Warnings incorrectly suppressed when compiling previously preprocessed file
Date: Wed, 04 Jun 2014 16:23: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu 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:
Message-ID: <bug-61412-4-zScOzcQ63u@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00306.txt.bz2
Content-length: 175

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
but maybe it is a dup of PR60723.
>From gcc-bugs-return-453225-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 04 16:27:36 2014
Return-Path: <gcc-bugs-return-453225-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10314 invoked by alias); 4 Jun 2014 16:27:35 -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 10256 invoked by uid 48); 4 Jun 2014 16:27:32 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61412] Warnings incorrectly suppressed when compiling previously preprocessed file
Date: Wed, 04 Jun 2014 16:27: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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:
Message-ID: <bug-61412-4-98kh1co6Qx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61412-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: 2014-06/txt/msg00307.txt.bz2
Content-length: 796

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Matt Godbolt from comment #5)
> In the original file the "# ..."
> line came from the middle of a macro expansion defined by a header included
> via an -isystem path.

That's the real problem: we don't emit warnings for macros defined in system
headers, even though the expansion of the macro is not in a system header.

I think there's an existing report about that too.

> The filename in the "# " line refers to the C++ file
> though in both cases.

But in a context that makes the compiler think it's a system header file. I
think your reduction of the preprocessed output misled you to think the problem
was related to all preprocessed output, but it's not.

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the reduced testcase this actually regressed already in November 2005 or so,
so doesn't look anything close to a recent regression.

David, can you please have a look?

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think what is important that if the other conditions besides mini_p != 0 are
not met, then control flow goes to basic blocks from which there is no path to
the bb with the use (in this testcase just to the return bb or empty blocks
that directly or indirectly fall thru into the return bb and the use is not in
the return bb).

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

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

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Of particular interest is this PHI node at the start of BB6:

  # mw_1 = PHI <mw_9(D)(2), h_33(5)>


I vaguely remember that we had code that would optimize this case, specifically
we would ignore PHI alternatives associated with undefined uses.  If we did
that, then we'd create an equivalence mw_1 = h33 which would then propagate to
the use of mw_1 and replace it with h33 and avoid the false positive.  I
thought that was in the vrp/ccp propagation engine.

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Sigh.  We can't do the propagation, even if we recognize the mw_9 default
definition represents an undefined value -- because doing so would result in a
use that is not dominated by its def.

We could do duplication and essentially create

if (mini_p)
  {
    long int a = make_window ();
    if (!PSEUDOVECTORP (a)) return rw;
    mw  = (void*) a - 5;
    rw->pixel_width = ((rw->text_cols * (rw->column_width))
                     + (rw->left_fringe_width + (rw->right_fringe_width)) + 2 *
(rw->internal_border_width));
    rw->pixel_height = ((rw->text_cols * (rw->line_height)));
    mw->pixel_height = rw->pixel_height;
  }
else
  {
    rw->pixel_width = ((rw->text_cols * (rw->column_width))
                     + (rw->left_fringe_width + (rw->right_fringe_width)) + 2 *
(rw->internal_border_width));
    rw->pixel_height = ((rw->text_cols * (rw->line_height)));
  }


And in fact, that's precisely what the code to handle joiner blocks in the jump
threader is supposed to do...   Hmmm, this might be mine...

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alserkli at inbox dot ru

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
*** Bug 64823 has been marked as a duplicate of this bug. ***

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> ---
So we don't thread this case because of the limits we place on the number of
statements in the duplicated block.

If --param max-jump-thread-duplication-stmts=16 is added to the command line,
jump threading will kick in creating the pseudo-code I posted in c#11.  For
reference, the default value of that param is 15.

What I don't understand from c#4 is uninit can't simplify this condition:

if (_35 == 4611686018595160064 (.AND.)  (.NOT.) _31 != 5) is false

While we may not know the full condition, does realizing that the (*.NOT.) _31
!= 5 is totally pointless help?

[Bug middle-end/61409] [4.9/5 regression] -Wmaybe-uninitialized false-positive with -O2

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
And even simpler testcase:


void *init(void);

struct window
{
  int line_height;
  int pixel_width;
  int pixel_height;
  int column_width;
  int text_cols;
  int internal_border_width;
  int left_fringe_width, right_fringe_width;
} *rw;

void bar() __attribute__((noreturn));
void f(int i, int j) {
    void *ptr;
    if (i)
      {
        if (j)
          return; /* bar(); */
        ptr = init();
      }
    rw->pixel_width = ((rw->text_cols * (rw->column_width))
                       + (rw->left_fringe_width + (rw->right_fringe_width)) + 2
* (rw->internal_border_width));
  rw->pixel_height = ((rw->text_cols * (rw->line_height)));
  if (i)
    {
      rw=ptr;
    }
}


And the dump:

f (intD.6 iD.1843, intD.6 jD.1844)
{
  voidD.41 * ptrD.1847;
  struct window * rw.0_10;
  intD.6 _11;
  intD.6 _12;
  intD.6 _13;
  intD.6 _14;
  intD.6 _15;
  intD.6 _16;
  intD.6 _17;
  intD.6 _18;
  intD.6 _19;
  intD.6 _20;
  intD.6 _22;
  intD.6 _23;

;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 0, next block 9, flags: (NEW, REACHABLE)
;;    pred:       ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
;;   starting at line 17
  [test.c:17:8] if (i_4(D) != 0)
    goto <bb 3>;
  else
    goto <bb 9>;
;;    succ:       3 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;                9 [50.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 9, loop depth 0, count 0, freq 5000, maybe hot
;;    prev block 2, next block 3, flags: (NEW)
;;    pred:       2 [50.0%]  (FALSE_VALUE,EXECUTABLE)
;; 
  goto <bb 6>;
;;    succ:       6 [100.0%]  (FALLTHRU)

;;   basic block 3, loop depth 0, count 0, freq 5000, maybe hot
;;    prev block 9, next block 10, flags: (NEW, REACHABLE)
;;    pred:       2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;   starting at line 19
  [test.c:19:5] if (j_7(D) != 0)
    goto <bb 10>;
  else
    goto <bb 5>;
;;    succ:       10 [61.0%]  (TRUE_VALUE,EXECUTABLE)
;;                5 [39.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 10, loop depth 0, count 0, freq 3051, maybe hot
;;    prev block 3, next block 4, flags: (NEW)
;;    pred:       3 [61.0%]  (TRUE_VALUE,EXECUTABLE)
;; 
;;    succ:       4 [100.0%]  (FALLTHRU)

;;   basic block 4, loop depth 0, count 0, freq 5761, maybe hot
;;    prev block 10, next block 5, flags: (NEW)
;;    pred:       10 [100.0%]  (FALLTHRU)
;;                11 [100.0%]  (FALLTHRU)
;; 
  # .MEM_47 = PHI <.MEM_6(D)(10), .MEM_24(11)>
  goto <bb 8>;
;;    succ:       8 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 5, loop depth 0, count 0, freq 1949, maybe hot
;;    prev block 4, next block 6, flags: (NEW, REACHABLE)
;;    pred:       3 [39.0%]  (FALSE_VALUE,EXECUTABLE)
;;   starting at line 21
  [test.c:21:6] # .MEM_8 = VDEF <.MEM_6(D)>
  # PT = nonlocal escaped 
  # USE = nonlocal 
  # CLB = nonlocal 
  ptr_9 = initD.1831 ();
;;    succ:       6 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 6, loop depth 0, count 0, freq 6949, maybe hot
;;    prev block 5, next block 11, flags: (NEW, REACHABLE)
;;    pred:       9 [100.0%]  (FALLTHRU)
;;                5 [100.0%]  (FALLTHRU,EXECUTABLE)
;;   starting at line 23
  # PT = nonlocal escaped 
  # ptr_1 = PHI <ptr_5(D)(9), [test.c:21:6] ptr_9(5)>
  # .MEM_2 = PHI <.MEM_6(D)(9), .MEM_8(5)>
  [test.c:23:27] # VUSE <.MEM_2>
  # PT = nonlocal escaped 
  rw.0_10 = rwD.1841;
  [test.c:23:27] # VUSE <.MEM_2>
  _11 = [test.c:23:27] rw.0_10->text_colsD.1837;
  [test.c:23:44] # VUSE <.MEM_2>
  _12 = [test.c:23:44] rw.0_10->column_widthD.1836;
  [test.c:23:39] _13 = _11 * _12;
  [test.c:24:15] # VUSE <.MEM_2>
  _14 = [test.c:24:15] rw.0_10->left_fringe_widthD.1839;
  [test.c:24:40] # VUSE <.MEM_2>
  _15 = [test.c:24:40] rw.0_10->right_fringe_widthD.1840;
  [test.c:24:35] _16 = _14 + _15;
  [test.c:24:10] _17 = _13 + _16;
  [test.c:24:72] # VUSE <.MEM_2>
  _18 = [test.c:24:72] rw.0_10->internal_border_widthD.1838;
  [test.c:24:67] # RANGE [-2147483648, 2147483647] NONZERO 4294967294
  _19 = _18 * 2;
  [test.c:24:63] _20 = _17 + _19;
  [test.c:23:21] # .MEM_21 = VDEF <.MEM_2>
  [test.c:23:7] rw.0_10->pixel_widthD.1834 = _20;
  [test.c:25:43] # VUSE <.MEM_21>
  _22 = [test.c:25:43] rw.0_10->line_heightD.1833;
  [test.c:25:38] _23 = _11 * _22;
  [test.c:25:20] # .MEM_24 = VDEF <.MEM_21>
  [test.c:25:5] rw.0_10->pixel_heightD.1835 = _23;
  [test.c:26:6] if (i_4(D) != 0)
    goto <bb 7>;
  else
    goto <bb 11>;
;;    succ:       7 [61.0%]  (TRUE_VALUE,EXECUTABLE)
;;                11 [39.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 11, loop depth 0, count 0, freq 2710, maybe hot
;;    prev block 6, next block 7, flags: (NEW)
;;    pred:       6 [39.0%]  (FALSE_VALUE,EXECUTABLE)
;; 
  goto <bb 4>;
;;    succ:       4 [100.0%]  (FALLTHRU)

;;   basic block 7, loop depth 0, count 0, freq 4239, maybe hot
;;    prev block 11, next block 8, flags: (NEW, REACHABLE)
;;    pred:       6 [61.0%]  (TRUE_VALUE,EXECUTABLE)
;;   starting at line 28
  [test.c:28:9] # .MEM_25 = VDEF <.MEM_24>
  rwD.1841 = ptr_1;
;;    succ:       8 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 8, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 7, next block 1, flags: (NEW, REACHABLE)
;;    pred:       4 [100.0%]  (FALLTHRU,EXECUTABLE)
;;                7 [100.0%]  (FALLTHRU,EXECUTABLE)
;;   starting at line -1, discriminator 1
  # .MEM_3 = PHI <.MEM_47(4), .MEM_25(7)>
  # VUSE <.MEM_3>
  return;
;;    succ:       EXIT [100.0%] 

}

I don't really understand how the uninit pass computes the predicates, but when
replacing the "return" with "bar()", it is able to see that "j != 0" is not
part of the predicate guarding the def of ptr. Thus, somehow the analysis that
works for a noreturn function fails for a normal return.
>From gcc-bugs-return-479045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 02 19:36:49 2015
Return-Path: <gcc-bugs-return-479045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 59828 invoked by alias); 2 Mar 2015 19:36:49 -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 59517 invoked by uid 48); 2 Mar 2015 19:36:45 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65256] [5 regression] Undefined symbols linking f951
Date: Mon, 02 Mar 2015 19:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-65256-4-8C9RjkdjPr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65256-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65256-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-03/txt/msg00189.txt.bz2
Content-length: 585

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

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

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

--- Comment #1 from Jeffrey A. Law <law at redhat dot com> ---
John, is this with SOM or ELF?  If the former, it looks like something might be
missing its .import/.export statement.  What do the underlying symbols look
like for the reference and the definition of those symbols?

[Bug middle-end/61409] [4.9/5/6 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug middle-end/61409] [4.9/5/6 regression] -Wmaybe-uninitialized false-positive with -O2

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4