public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "vincent-gcc at vinc17 dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 08:40:00 -0000 [thread overview]
Message-ID: <bug-60165-4-8UZJmnd3Qe@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #2 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Well, the code paths in question do not necessarily exist (you could say the
same thing with -O2, where the function is not inlined: there may be some code
paths for which fn1() doesn't initialize c).
Actually the number of "maybe-uninitialized" warnings should decrease when the
optimization level increases, because of additional knowledge, not the
opposite.
>From gcc-bugs-return-443438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 08:47:27 2014
Return-Path: <gcc-bugs-return-443438-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8363 invoked by alias); 13 Feb 2014 08:47:26 -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 8280 invoked by uid 48); 13 Feb 2014 08:47:23 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60165] "may be used uninitialized" warning with -O3 but not with -O2
Date: Thu, 13 Feb 2014 08:47: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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-60165-4-aRKPy0Zwbi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60165-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60165-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-02/txt/msg01195.txt.bz2
Content-length: 1588
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #2)
> Well, the code paths in question do not necessarily exist (you could say the
> same thing with -O2, where the function is not inlined: there may be some
> code paths for which fn1() doesn't initialize c).
The code path exists in the code, the fact that perhaps in your program such
code path is never taken doesn't mean it is undesirable to warn about it.
GCC has two kinds of warnings, the is uninitialized one where particular code,
if executed, will always use uninitialized value, and maybe uninitialized,
where it will use uninitialized value only conditionally. That is the case
here.
>
> Actually the number of "maybe-uninitialized" warnings should decrease when
> the optimization level increases, because of additional knowledge, not the
> opposite.
No, usually with more inlining it increases and should. When fn1 is not
inlined, GCC intentionally does not warn that c might be uninitialized because
maybe the function call could use the value or not set it unconditionally, that
would lead to so huge amount of false positives for the warning that nobody
would be willing to use the warning.
>From gcc-bugs-return-443439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 13 08:56:18 2014
Return-Path: <gcc-bugs-return-443439-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11413 invoked by alias); 13 Feb 2014 08:56:18 -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 11371 invoked by uid 48); 13 Feb 2014 08:56:13 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60167] [4.8/4.9 regression] Bogus error: conflicting declaration
Date: Thu, 13 Feb 2014 08:56: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: priority bug_status cf_reconfirmed_on cc target_milestone short_desc everconfirmed
Message-ID: <bug-60167-4-3pUcSZtbKW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60167-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60167-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-02/txt/msg01196.txt.bz2
Content-length: 1009
http://gcc.gnu.org/bugzilla/show_bug.cgi?id`167
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-02-13
CC| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org
Target Milestone|--- |4.8.3
Summary|[4.9 regression] Bogus |[4.8/4.9 regression] Bogus
|error: conflicting |error: conflicting
|declaration |declaration
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r207167 and in r207189 has been introduced on the 4.8 branch as
well.
next prev parent reply other threads:[~2014-02-13 8:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 3:17 [Bug tree-optimization/60165] New: " vincent-gcc at vinc17 dot net
2014-02-13 8:40 ` vincent-gcc at vinc17 dot net [this message]
2014-02-13 9:21 ` [Bug tree-optimization/60165] " rguenth at gcc dot gnu.org
2014-02-13 10:09 ` vincent-gcc at vinc17 dot net
2014-02-13 10:17 ` jakub at gcc dot gnu.org
2014-02-13 10:29 ` vincent-gcc at vinc17 dot net
2014-02-13 12:14 ` vincent-gcc at vinc17 dot net
2014-02-13 12:57 ` glisse at gcc dot gnu.org
2014-02-13 13:33 ` vincent-gcc at vinc17 dot net
2014-02-13 13:48 ` vincent-gcc at vinc17 dot net
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-60165-4-8UZJmnd3Qe@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).