public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug driver/63660] New: [4.8-4.9+] -Wmaybe-uninitialized false positive with -O1 and more
@ 2014-10-27 18:32 ed0.88.prez at gmail dot com
  2014-10-28  9:04 ` [Bug tree-optimization/63660] " rguenth at gcc dot gnu.org
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: ed0.88.prez at gmail dot com @ 2014-10-27 18:32 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-08-30  8:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-27 18:32 [Bug driver/63660] New: [4.8-4.9+] -Wmaybe-uninitialized false positive with -O1 and more ed0.88.prez at gmail dot com
2014-10-28  9:04 ` [Bug tree-optimization/63660] " rguenth at gcc dot gnu.org
2014-12-03 14:15 ` [Bug tree-optimization/63660] -Wmaybe-uninitialized false positive (uninit pass limits) ed0.88.prez at gmail dot com
2014-12-03 14:52 ` manu at gcc dot gnu.org
2021-03-31  2:17 ` msebor at gcc dot gnu.org
2022-08-30  8:01 ` [Bug tree-optimization/63660] -Wmaybe-uninitialized false positive on many repeated bitwise tests rguenth at gcc dot gnu.org
2022-08-30  8:05 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).