[Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)

["vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #20 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> 2013-04-17 11:17:14 UTC ---
(In reply to comment #18)
> In fact, we should have removed the i=i idiom a long time ago. The correct
> thing to do (as Linus says) is to initialize the variable to a sensible value
> to silence the warning: http://lwn.net/Articles/529954/

There is no real sensible value except some trap value. Letting the variable
uninitialized at that point (the declaration) allows some tools, like the
Formalin compiler described in WG14/N1637, to detect potential problems if the
variable is really used uninitialized.

(In reply to comment #19)
> Note that -Wmaybe-uninitialized is available since at least GCC 4.8.0

OK, so a solution would be to add a configure test for projects that don't want
such warnings (while still using -Wall) to see whether -Wno-maybe-uninitialized
is supported.
>From gcc-bugs-return-420461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:26:04 2013
Return-Path: <gcc-bugs-return-420461-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22867 invoked by alias); 17 Apr 2013 11:26:04 -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 22832 invoked by uid 48); 17 Apr 2013 11:26:01 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
Date: Wed, 17 Apr 2013 11:26: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
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: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36296-4-TYCh4HRdTc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01606.txt.bz2
Content-length: 861


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

--- Comment #21 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 11:26:01 UTC ---
(In reply to comment #20)
> OK, so a solution would be to add a configure test for projects that don't want
> such warnings (while still using -Wall) to see whether -Wno-maybe-uninitialized
> is supported.

When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC
will emit a diagnostic stating that the option is not recognized.  However, if
the -Wno- form is used, the behavior is slightly different: No diagnostic will
be
produced for -Wno-unknown-warning unless other diagnostics are being produced. 
This allows the use of new -Wno- options with old compilers, but if something
goes wrong, the compiler will warn that an unrecognized option was used.
>From gcc-bugs-return-420462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:31:33 2013
Return-Path: <gcc-bugs-return-420462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25982 invoked by alias); 17 Apr 2013 11:31: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 25943 invoked by uid 48); 17 Apr 2013 11:31:30 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/36296] bogus uninitialized warning (loop representation, VRP missed-optimization)
Date: Wed, 17 Apr 2013 11:31: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-Keywords: diagnostic
X-Bugzilla-Severity: normal
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: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36296-4-7NV6JZXQFe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36296-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01607.txt.bz2
Content-length: 1107


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

--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-04-17 11:31:29 UTC ---
(In reply to comment #20)
> (In reply to comment #18)
> > In fact, we should have removed the i=i idiom a long time ago. The correct
> > thing to do (as Linus says) is to initialize the variable to a sensible value
> > to silence the warning: http://lwn.net/Articles/529954/
> 
> There is no real sensible value except some trap value. Letting the variable
> uninitialized at that point (the declaration) allows some tools, like the
> Formalin compiler described in WG14/N1637, to detect potential problems if the
> variable is really used uninitialized.

That doesn't contradict my assessment above that i=i idiom should die. With the
Pragma one can choose to ignore GCC warnings if they don't want to initialize
the value.

The trap value would be an additional improvement, but someone needs to
implement it. Clang has fsanitize=undefined-trap:

http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation
>From gcc-bugs-return-420463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 17 11:41:24 2013
Return-Path: <gcc-bugs-return-420463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30907 invoked by alias); 17 Apr 2013 11:41:24 -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 30628 invoked by uid 48); 17 Apr 2013 11:41:21 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/56814] [4.8/4.9 Regression] Bogus Interface mismatch in dummy procedure
Date: Wed, 17 Apr 2013 11:41: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-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: janus at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56814-4-2UWiT3c1Em@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56814-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56814-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01608.txt.bz2
Content-length: 250


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

--- Comment #6 from janus at gcc dot gnu.org 2013-04-17 11:41:21 UTC ---
(In reply to comment #5)
> Alternative patch:

In contrast to the patch in comment #3, this one regtests cleanly ...