[Bug driver/63660] New: [4.8-4.9+] -Wmaybe-uninitialized false positive with -O1 and more

["ed0.88.prez at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 63660
           Summary: [4.8-4.9+] -Wmaybe-uninitialized false positive with
                    -O1 and more
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ed0.88.prez at gmail dot com

Here, this code:

cat bug.i
typedef struct
{
 int a;
 int b;
 int c;
 int d;
 int e;
 int f;
 int g;
 int h;
 int i;
 int j;
} X;

X *XX(int);

int G();

static void F()
{
 X *x;
 int m, n;
 int xa, xb, xc, xd, xe, xf, xg, xh, xi, xj;

 m = G();
 n = G();
 if ( n & 1 ) xa = G();
 if ( n & 2 ) xb = G();
 if ( n & 4 ) xc = G();
 if ( n & 32 ) xd = G();
 if ( n & 16 ) xe = G();
 if ( n & 64 ) xf = G();
 if ( n & 256 ) xg = G();
 if ( n & 512 ) xh = G();
 if ( n & 1024 ) xi = G();
 if ( n & 2048 ) xj = G();

 if ( m >= 64 ) return;
 x = XX(m);
 if ( n & 1 ) x->a = xa;
 if ( n & 2 ) x->b = xb;
 if ( n & 4 ) x->c = xc;
 if ( n & 32 ) x->d = xd;
 if ( n & 16 ) x->e = xe;
 if ( n & 64 ) x->f = xf;
 if ( n & 256 ) x->g = xg;
 if ( n & 512 ) x->h = xh;
 if ( n & 1024 ) x->i = xi;
 if ( n & 2048 ) x->j = xj;
}

void H()
{
 F();
}
EOF

Compiled with -O1 -Wmaybe-uninitialized (implied by -Wall), reports this
message:

bug.i: In function ‘H’:
bug.i:49:23: warning: ‘xj’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  if ( n & 2048 ) x->j = xj;
                       ^
bug.i:23:42: note: ‘xj’ was declared here
  int xa, xb, xc, xd, xe, xf, xg, xh, xi, xj;
                                          ^
This code is a very reduced testcase from a large program.
>From gcc-bugs-return-465081-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 27 18:32:48 2014
Return-Path: <gcc-bugs-return-465081-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4938 invoked by alias); 27 Oct 2014 18:32: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 4890 invoked by uid 48); 27 Oct 2014 18:32:44 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
Date: Mon, 27 Oct 2014 18:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63620-4-0Ih33qX9Lc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63620-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63620-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-10/txt/msg02102.txt.bz2
Content-length: 811

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

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
The more I watch the %ebx PIC problems, the more this reminds me of secondary
reloads and I wonder if we defined those properly if the right things would
happen.

This kind of thing has shown up on other architectures.  For example, on the
PA, if you try to load a symbolic constant into an FP register while generating
PIC code, you have to generate a secondary reload using %r1 as a scratch.

It's not a perfect match in that we don't need a scratch, but instead the PIC
register to be live, but it's pretty damn close.

I haven't looked at LRA's handling of secondary reloads, but it may be worth
someone's time to do so to see if it can be used to show %ebx as being needed
in these cases.