public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
@ 2014-10-03 0:16 ` manu at gcc dot gnu.org
2014-10-03 7:10 ` glisse at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: manu at gcc dot gnu.org @ 2014-10-03 0:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-10-03
CC| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
> In an ideal world gcc would warn about the last line of make_foo() instead
> of func(), and it would mention a dangling reference instead of an
> uninitialized use.
Hum, yes, but I'm not even sure if GCC realizes that there is a dangling
reference. However, it should since the code looks like:
foo make_foo() ()
Eh tree:
1 cleanup
2 cleanup
{
intD.9 & SR.1D.2273;
intD.9 xD.2244;
struct fooD.2226 D.2254;
struct fooD.2226 D.2260;
;; basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;; prev block 0, next block 1, flags: (NEW, REACHABLE)
;; pred: ENTRY (FALLTHRU,EXECUTABLE)
;; starting at line 10
[test.c : 10:11] # .MEM_2 = VDEF <.MEM_1(D)>
xD.2244 = 42;
[test.c : 11:15] # .MEM_4 = VDEF <.MEM_2>
[test.c : 11] MEM[(struct fooD.2226 *)&D.2260] = &xD.2244;
# .MEM_6 = VDEF <.MEM_4>
xD.2244 ={v} {CLOBBER};
[test.c : 11:15] # VUSE <.MEM_6>
return D.2260;
;; succ: EXIT (EXECUTABLE)
}
which is just before x = 42 is removed. But for the same reason that it is
removed, perhaps also the dangling reference could be detected.
>From gcc-bugs-return-463152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 01:32:49 2014
Return-Path: <gcc-bugs-return-463152-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28306 invoked by alias); 3 Oct 2014 01:32: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 28273 invoked by uid 48); 3 Oct 2014 01:32:45 -0000
From: "bobby.prani at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63444] Compilation consumes 2.5G memory
Date: Fri, 03 Oct 2014 01:32: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bobby.prani at gmail dot com
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-63444-4-zluQYyvaF4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63444-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63444-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/msg00173.txt.bz2
Content-length: 178
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc444
--- Comment #1 from Pranith Kumar <bobby.prani at gmail dot com> ---
Just FYI, clang compiles the same file using 1G memory.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
2014-10-03 0:16 ` [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized manu at gcc dot gnu.org
@ 2014-10-03 7:10 ` glisse at gcc dot gnu.org
2014-10-03 7:18 ` glisse at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-10-03 7:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
make_foo:
MEM[(struct foo *)&D.2281] = &x;
x ={v} {CLOBBER};
return D.2281;
That doesn't seem so easy to warn about. We could walk from return to find some
of the latest non-clobbered dominating writes to that variable, then if it is
an ADDR_EXPR look for dominating clobbers, but that would be very specialized,
slight variations on this code would not warn (and all those walks may start to
get costly if we do them naively). It is easier to warn in the caller when it
tries to dereference the dangling pointer.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
2014-10-03 0:16 ` [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized manu at gcc dot gnu.org
2014-10-03 7:10 ` glisse at gcc dot gnu.org
@ 2014-10-03 7:18 ` glisse at gcc dot gnu.org
2014-10-03 11:37 ` manu at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-10-03 7:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> make_foo:
>
> MEM[(struct foo *)&D.2281] = &x;
> x ={v} {CLOBBER};
> return D.2281;
>
> That doesn't seem so easy to warn about. We could walk from return to find
> some of the latest non-clobbered dominating writes to that variable, then if
> it is an ADDR_EXPR look for dominating clobbers, but that would be very
> specialized,
Hmm, actually, we can probably ignore the clobber, returning an object that
contains a pointer to a local variable is the issue. That's already a bit more
doable.
Not sure what the best pass would be to add this though. Returning (directly) a
pointer to a temporary is handled in isolate-paths IIRC, but that might not be
as good a fit for this.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-10-03 7:18 ` glisse at gcc dot gnu.org
@ 2014-10-03 11:37 ` manu at gcc dot gnu.org
2014-10-03 12:13 ` glisse at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: manu at gcc dot gnu.org @ 2014-10-03 11:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> make_foo:
>
> MEM[(struct foo *)&D.2281] = &x;
> x ={v} {CLOBBER};
> return D.2281;
>
> That doesn't seem so easy to warn about. We could walk from return to find
> some of the latest non-clobbered dominating writes to that variable, then if
> it is an ADDR_EXPR look for dominating clobbers, but that would be very
> specialized, slight variations on this code would not warn (and all those
> walks may start to get costly if we do them naively). It is easier to warn
> in the caller when it tries to dereference the dangling pointer.
At some moment (in dcce1), gcc decides that x = 4 is not needed. For the same
reason, it could realize that MEM[(struct foo *)&D.2281] = &x must produce a
dangling reference, no?
>From gcc-bugs-return-463176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:06:32 2014
Return-Path: <gcc-bugs-return-463176-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13188 invoked by alias); 3 Oct 2014 12:06:31 -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 13149 invoked by uid 48); 3 Oct 2014 12:06:26 -0000
From: "svante.signell at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63448] ICE when compiling atlas 3.10.2
Date: Fri, 03 Oct 2014 12:06: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: svante.signell at gmail dot com
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-63448-4-jjNWWdQKoG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63448-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63448-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/msg00197.txt.bz2
Content-length: 189
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc448
--- Comment #5 from Svante Signell <svante.signell at gmail dot com> ---
FYI: atlas builds fine with gcc-4.8.3-11 (and gfortran-4.9-15)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-10-03 11:37 ` manu at gcc dot gnu.org
@ 2014-10-03 12:13 ` glisse at gcc dot gnu.org
2014-10-03 13:51 ` glisse at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 8+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-10-03 12:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> At some moment (in dcce1), gcc decides that x = 4 is not needed. For the
> same reason, it could realize that MEM[(struct foo *)&D.2281] = &x must
> produce a dangling reference, no?
A clobber implies that the content is lost, so it is useless to store something
there right before the clobber (I assume that's why the store is removed, I
didn't check), but I don't believe it implies that the memory location is
reclaimed (does it?), so it would be fine to store a pointer in some struct,
kill what that pointer points to, re-create something there, use that, etc.
Without the return statement, it is normal to remove x=4 (because of the
clobber), but I don't see anything to warn about, while we could warn with a
return statement and no clobber, so the 2 things seem quite different.
Of course I may be looking at this the wrong way.
>From gcc-bugs-return-463178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:28:49 2014
Return-Path: <gcc-bugs-return-463178-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23047 invoked by alias); 3 Oct 2014 12:28: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 22991 invoked by uid 48); 3 Oct 2014 12:28:41 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63445] request: make -Wstrict-overflow avoid a class of false positives
Date: Fri, 03 Oct 2014 12:28: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: 5.0
X-Bugzilla-Keywords:
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-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-63445-4-AFzRvOLTHT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63445-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63445-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-10/txt/msg00199.txt.bz2
Content-length: 1208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-10-03
CC| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I'm going to confirm this even if it is not clear it is possible to fix this.
Also, I think it is a bug that the loop condition has the location of the "for"
keyword and not of the "<" expression when lowering to gimple. That is,
[test.c : 8:7] if (iD.1622 < nD.1621) goto <D.1623>; else goto <D.1625>;
should be
[test.c : 8:33] if (iD.1622 < nD.1621) goto <D.1623>; else goto <D.1625>;
It gets even more confusing if the "i < n" is in the next line:
test.c:8:7: warning: assuming signed overflow does not occur when simplifying
conditional [-Wstrict-overflow]
for (unsigned int i = 0;
^
>From gcc-bugs-return-463179-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:39:27 2014
Return-Path: <gcc-bugs-return-463179-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28971 invoked by alias); 3 Oct 2014 12:39:27 -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 28945 invoked by uid 48); 3 Oct 2014 12:39:23 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
Date: Fri, 03 Oct 2014 12:39: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.6.0
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-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63446-4-ILsL62HwN3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63446-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63446-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-10/txt/msg00200.txt.bz2
Content-length: 1500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #5)
> A clobber implies that the content is lost, so it is useless to store
> something there right before the clobber (I assume that's why the store is
> removed, I didn't check), but I don't believe it implies that the memory
> location is reclaimed (does it?), so it would be fine to store a pointer in
> some struct, kill what that pointer points to, re-create something there,
> use that, etc. Without the return statement, it is normal to remove x=4
> (because of the clobber), but I don't see anything to warn about, while we
> could warn with a return statement and no clobber, so the 2 things seem
> quite different.
OK, that makes sense. Thanks for the explanation.
What about checking that the return value, if it is a VUSE, is not assigned to
a local? That is, this would be valid, assuming y is not local,
MEM[(struct foo *)&D.2281] = &x;
MEM[(struct foo *)&D.2281] = &y;
return D.2281;
but this would not be:
MEM[(struct foo *)&D.2281] = &x;
return D.2281;
It doesn't matter, whether x is clobbered or has a value and also it doesn't
matter what is executed between the assignment and the return as long as it
doesn't change the value of MEM[(struct foo *)&D.2281]. It could be a matter of
following the chain of VUSE->VDEF, which I think we already do for
Wuninitialized.
>From gcc-bugs-return-463180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 12:40:01 2014
Return-Path: <gcc-bugs-return-463180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29726 invoked by alias); 3 Oct 2014 12:40:01 -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 29693 invoked by uid 48); 3 Oct 2014 12:39:57 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63449] documentation of vector space overhead management
Date: Fri, 03 Oct 2014 12:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-63449-4-rK9bSzleux@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63449-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63449-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/msg00201.txt.bz2
Content-length: 920
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc449
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |documentation
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-10-03
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
("documentation" is a keyword, the component should be "libstdc++" so that the
relevant maintainers deal with it.)
I don't know/remember anything about that new implementation, but it never
happened so I think we can just remove the section.
The list::size() documentation above needs updating though.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-10-03 12:13 ` glisse at gcc dot gnu.org
@ 2014-10-03 13:51 ` glisse at gcc dot gnu.org
2014-10-03 14:57 ` manu at gcc dot gnu.org
2021-04-16 17:17 ` msebor at gcc dot gnu.org
7 siblings, 0 replies; 8+ messages in thread
From: glisse at gcc dot gnu.org @ 2014-10-03 13:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #7 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #6)
> What about [...]
That's roughly what I describe in comment #2, amended by comment #3.
> It could be a matter of following the chain of VUSE->VDEF,
> which I think we already do for Wuninitialized.
IIRC we don't, and the file contains a comment saying that it would be
expensive. Actually, properly limiting the maximal depth of the walk (as is
done in several other passes) would make it cheap enough and we should probably
do it.
Note that if make_foo was static or inline, it wouldn't exist anymore in the
uninit pass.
>From gcc-bugs-return-463192-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 14:23:20 2014
Return-Path: <gcc-bugs-return-463192-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16454 invoked by alias); 3 Oct 2014 14:23: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 15793 invoked by uid 48); 3 Oct 2014 14:23:13 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
Date: Fri, 03 Oct 2014 14:23: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone short_desc
Message-ID: <bug-57003-4-iQXYijFA3F@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57003-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57003-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-10/txt/msg00213.txt.bz2
Content-length: 5637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
Target Milestone|4.8.1 |5.0
Summary|[4.8/4.9 Regression] |[4.8/4.9/5.0 Regression]
|gcc-4.8.0 breaks -O2 |gcc breaks -O2 optimization
|optimization with Wine(64) |with Wine(64) -
|- links/info/bisect of |links/info/bisect of
|commits included |commits included
--- Comment #23 from Uroš Bizjak <ubizjak at gmail dot com> ---
My r215428 change regressed this PR again. The difference is:
--- pr57003.s 2014-10-03 15:08:24.000000000 +0200
+++ pr57003_.s 2014-10-03 15:08:19.000000000 +0200
@@ -78,7 +78,7 @@
leaq -20(%rbx), %rdx
movq %rax, %rdi
call memcpy
- movq %rdi, c(%rip)
+ movq %rax, c(%rip)
.L8:
movaps (%rsp), %xmm6
movaps 16(%rsp), %xmm7
@@ -321,5 +321,5 @@
.byte 0xb
.align 8
.LEFDE7:
- .ident "GCC: (GNU) 5.0.0 20141002 (experimental) [trunk revision
215797]"
+ .ident "GCC: (GNU) 4.9.2 20141001 (prerelease) [gcc-4_9-branch
revision 215749]"
.section .note.GNU-stack,"",@progbits
So, gcc-5.0 does not detect that %rdi is clobbered in ELF ABI.
The runtime failure happens only on CentOS5 (and not in Fedora20), which
supports findings in Comment #17.
The difference is, that previously we emit memcpy call as:
#(call_insn:TI 24 23 27 3 (set (reg:DI 0 ax)
# (call (mem:QI (symbol_ref:DI ("memcpy") [flags 0x41] <function_decl
0x7fce6f586438 memcpy>) [0 memcpy S1 A8])
# (const_int 0 [0]))) pr57003.c:32 661 {*call_value}
# (expr_list:REG_DEAD (reg:DI 5 di)
# (expr_list:REG_DEAD (reg:DI 4 si)
# (expr_list:REG_DEAD (reg:DI 1 dx)
# (expr_list:REG_UNUSED (reg:DI 0 ax)
# (expr_list:REG_RETURNED (reg/v/f:DI 2 cx [orig:87 e ]
[87])
# (expr_list:REG_CALL_DECL (symbol_ref:DI ("memcpy")
[flags 0x41] <function_decl 0x7fce6f586438 memcpy>)
# (expr_list:REG_EH_REGION (const_int 0 [0])
# (nil))))))))
# (expr_list (clobber (reg:TI 52 xmm15))
# (expr_list (clobber (reg:TI 51 xmm14))
# (expr_list (clobber (reg:TI 50 xmm13))
# (expr_list (clobber (reg:TI 49 xmm12))
# (expr_list (clobber (reg:TI 48 xmm11))
# (expr_list (clobber (reg:TI 47 xmm10))
# (expr_list (clobber (reg:TI 46 xmm9))
# (expr_list (clobber (reg:TI 45 xmm8))
# (expr_list (clobber (reg:TI 28 xmm7))
# (expr_list (clobber (reg:TI 27 xmm6))
# (expr_list (clobber (reg:DI 5 di))
# (expr_list (clobber (reg:DI 4
si))
# (expr_list:DI (set (reg:DI
0 ax)
# (reg:DI 5 di))
# (expr_list:DI (use
(reg:DI 5 di))
# (expr_list:DI (use
(reg:DI 4 si))
# (expr_list:DI
(use (reg:DI 1 dx))
#
(nil))))))))))))))))))
which is alternate, but equivalent form of what was generated previously:
#(call_insn:TI 24 23 27 3 (parallel [
# (set (reg:DI 0 ax)
# (call (mem:QI (symbol_ref:DI ("memcpy") [flags 0x41]
<function_decl 0x7fd91824a800 memcpy>) [0 memcpy S1 A8])
# (const_int 0 [0])))
# (unspec [
# (const_int 0 [0])
# ] UNSPEC_MS_TO_SYSV_CALL)
# (clobber (reg:DI 4 si))
# (clobber (reg:DI 5 di))
# (clobber (reg:TI 27 xmm6))
# (clobber (reg:TI 28 xmm7))
# (clobber (reg:TI 45 xmm8))
# (clobber (reg:TI 46 xmm9))
# (clobber (reg:TI 47 xmm10))
# (clobber (reg:TI 48 xmm11))
# (clobber (reg:TI 49 xmm12))
# (clobber (reg:TI 50 xmm13))
# (clobber (reg:TI 51 xmm14))
# (clobber (reg:TI 52 xmm15))
# ]) pr57003.c:32 652 {*call_value_rex64_ms_sysv}
# (expr_list:REG_DEAD (reg:DI 5 di)
# (expr_list:REG_DEAD (reg:DI 4 si)
# (expr_list:REG_DEAD (reg:DI 1 dx)
# (expr_list:REG_RETURNED (reg/v/f:DI 2 cx [orig:87 e ] [87])
# (expr_list:REG_EH_REGION (const_int 0 [0])
# (nil))))))
# (expr_list:DI (set (reg:DI 0 ax)
# (reg:DI 5 di))
# (expr_list:DI (use (reg:DI 5 di))
# (expr_list:DI (use (reg:DI 4 si))
# (expr_list:DI (use (reg:DI 1 dx))
# (nil))))))
It looks that Jakub's patch, proposed in Comment #21 doesn't cover alternative
form, so it doesn't record clobbers in the alternative form properly.
Reopened as 5.0 regression.
>From gcc-bugs-return-463191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 14:23:13 2014
Return-Path: <gcc-bugs-return-463191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15794 invoked by alias); 3 Oct 2014 14:23:13 -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 15727 invoked by uid 48); 3 Oct 2014 14:23:06 -0000
From: "chefmax at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/58867] asan and ubsan tests not run for installed testing
Date: Fri, 03 Oct 2014 14:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chefmax at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pinskia at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58867-4-lql8eK33z8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58867-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58867-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/msg00212.txt.bz2
Content-length: 486
https://gcc.gnu.org/bugzilla/show_bug.cgi?idX867
Maxim Ostapenko <chefmax at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chefmax at gcc dot gnu.org
--- Comment #5 from Maxim Ostapenko <chefmax at gcc dot gnu.org> ---
This is fixed by r215793, but I forgot to mention it in commit message. So, ok
to resolve as fixed?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-10-03 13:51 ` glisse at gcc dot gnu.org
@ 2014-10-03 14:57 ` manu at gcc dot gnu.org
2021-04-16 17:17 ` msebor at gcc dot gnu.org
7 siblings, 0 replies; 8+ messages in thread
From: manu at gcc dot gnu.org @ 2014-10-03 14:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #7)
> IIRC we don't, and the file contains a comment saying that it would be
> expensive. Actually, properly limiting the maximal depth of the walk (as is
> done in several other passes) would make it cheap enough and we should
> probably do it.
I hope so. You may even fix PR19430 in the process, which is one of the oldest
PRs we have!
>From gcc-bugs-return-463202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 03 15:02:12 2014
Return-Path: <gcc-bugs-return-463202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30495 invoked by alias); 3 Oct 2014 15:02:12 -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 30437 invoked by uid 55); 3 Oct 2014 15:02:08 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63449] documentation of vector space overhead management
Date: Fri, 03 Oct 2014 15:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63449-4-BTYBDiypF3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63449-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63449-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/msg00223.txt.bz2
Content-length: 805
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc449
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Fri Oct 3 15:01:36 2014
New Revision: 215855
URL: https://gcc.gnu.org/viewcvs?rev!5855&root=gcc&view=rev
Log:
PR libstdc++/63449
* doc/xml/manual/containers.xml: Remove outdated section. Update
std::list notes.
* doc/html/*: Regenerate.
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/doc/html/index.html
branches/gcc-4_8-branch/libstdc++-v3/doc/html/manual/containers.html
branches/gcc-4_8-branch/libstdc++-v3/doc/html/manual/index.html
branches/gcc-4_8-branch/libstdc++-v3/doc/html/manual/std_contents.html
branches/gcc-4_8-branch/libstdc++-v3/doc/xml/manual/containers.xml
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2014-10-03 14:57 ` manu at gcc dot gnu.org
@ 2021-04-16 17:17 ` msebor at gcc dot gnu.org
7 siblings, 0 replies; 8+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-04-16 17:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2014-10-03 00:00:00 |2021-4-16
Known to fail| |10.2.0, 11.0, 4.6.4, 4.9.4,
| |5.5.0, 6.4.0, 7.2.0, 8.3.0,
| |9.1.0
CC| |msebor at gcc dot gnu.org
Severity|normal |enhancement
Blocks| |49974
--- Comment #9 from Martin Sebor <msebor at gcc dot gnu.org> ---
GCC 11 improves the message by including a note that mentions the uninitialized
variable. In this case it doesn't completely solve the problem because the
variable it points to is initialized but it should help.
pr63446.C: In function ‘int func()’:
pr63446.C:15:14: warning: ‘x’ is used uninitialized [-Wuninitialized]
15 | return f.ref;
| ^~~
pr63446.C:8:9: note: ‘x’ was declared here
8 | int x = 42;
| ^
But the underlying bug here is returning a reference to a local variable, so
the warning to improve is -Wreturn-local-addr. That will diagnose the return
statement in make_foo(). Bug 49974 tracks that enhancement. With that, the
additional -Wuninitialized issued in func() would just help clarify the
consequences of the bug but not otherwise be essential.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
[Bug 49974] missing -Wreturn-local-addr for indirectly returning reference to
local/temporary
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-04-16 17:17 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-63446-4@http.gcc.gnu.org/bugzilla/>
2014-10-03 0:16 ` [Bug tree-optimization/63446] dangling reference results in confusing diagnostic from -Wuninitialized manu at gcc dot gnu.org
2014-10-03 7:10 ` glisse at gcc dot gnu.org
2014-10-03 7:18 ` glisse at gcc dot gnu.org
2014-10-03 11:37 ` manu at gcc dot gnu.org
2014-10-03 12:13 ` glisse at gcc dot gnu.org
2014-10-03 13:51 ` glisse at gcc dot gnu.org
2014-10-03 14:57 ` manu at gcc dot gnu.org
2021-04-16 17:17 ` msebor 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).