public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/63698] New: std::set leaks nodes on assignement
@ 2014-10-31 9:15 adl at lrde dot epita.fr
2014-10-31 9:45 ` [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment redi at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: adl at lrde dot epita.fr @ 2014-10-31 9:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
Bug ID: 63698
Summary: std::set leaks nodes on assignement
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at lrde dot epita.fr
Compiling a project of mine with the latest gcc-snapshot distributed by Debian
(g++ (Debian 20141016-1) 5.0.0 20141016 (experimental) [trunk revision
216349]), I started to get memory leaks.
I reduced the problem to this small scenario:
% cat foo.cc
#include <set>
int main()
{
std::set<int> v{2,1}; // The order of 2 and 1 is important.
std::set<int> w{6,5,4};
v = w;
return v.size();
}
% g++ -std=c++11 foo.cc -g -Wall
% valgrind --leak-check=yes -q ./a.out
==30757== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==30757== at 0x4C29180: operator new(unsigned long)
(vg_replace_malloc.c:324)
==30757== by 0x40277D: __gnu_cxx::new_allocator<std::_Rb_tree_node<int>
>::allocate(unsigned long, void const*) (new_allocator.h:104)
==30757== by 0x4026F8:
std::allocator_traits<std::allocator<std::_Rb_tree_node<int> >
>::allocate(std::allocator<std::_Rb_tree_node<int> >&, unsigned long)
(alloc_traits.h:360)
==30757== by 0x402668: std::_Rb_tree<int, int, std::_Identity<int>,
std::less<int>, std::allocator<int> >::_M_get_node() (stl_tree.h:485)
==30757== by 0x40238D: std::_Rb_tree_node<int>* std::_Rb_tree<int, int,
std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_create_node<int
const&>(int const&) (stl_tree.h:539)
==30757== by 0x4021BE: std::_Rb_tree_node<int>* std::_Rb_tree<int, int,
std::_Identity<int>, std::less<int>, std::allocator<int>
>::_Alloc_node::operator()<int const&>(int const&) const (stl_tree.h:453)
==30757== by 0x401D82: std::_Rb_tree_iterator<int> std::_Rb_tree<int, int,
std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_<int
const&, std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>,
std::allocator<int> >::_Alloc_node>(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base*, int const&, std::_Rb_tree<int, int,
std::_Identity<int>, std::less<int>, std::allocator<int> >::_Alloc_node&)
(stl_tree.h:1381)
==30757== by 0x401324: std::_Rb_tree_iterator<int> std::_Rb_tree<int, int,
std::_Identity<int>, std::less<int>, std::allocator<int>
>::_M_insert_unique_<int const&, std::_Rb_tree<int, int, std::_Identity<int>,
std::less<int>, std::allocator<int>
>::_Alloc_node>(std::_Rb_tree_const_iterator<int>, int const&,
std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>,
std::allocator<int> >::_Alloc_node&) (stl_tree.h:1850)
==30757== by 0x400EF3: void std::_Rb_tree<int, int, std::_Identity<int>,
std::less<int>, std::allocator<int> >::_M_insert_unique<int const*>(int const*,
int const*) (stl_tree.h:2096)
==30757== by 0x400D0B: std::set<int, std::less<int>, std::allocator<int>
>::set(std::initializer_list<int>, std::less<int> const&, std::allocator<int>
const&) (stl_set.h:225)
==30757== by 0x400A6A: main (foo.cc:5)
I suspect this is related to what was implemented for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29988
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
@ 2014-10-31 9:45 ` redi at gcc dot gnu.org
2014-10-31 11:46 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-31 9:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-10-31
Known to work| |4.8.2, 4.9.2
Summary|std::set leaks nodes on |[5 Regression] std::set
|assignment |leaks nodes on assignment
Ever confirmed|0 |1
Known to fail| |5.0
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Alexandre Duret-Lutz from comment #0)
> I suspect this is related to what was implemented for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29988
Probably that, thanks for the minimal testcase.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
2014-10-31 9:45 ` [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment redi at gcc dot gnu.org
@ 2014-10-31 11:46 ` redi at gcc dot gnu.org
2014-10-31 12:53 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-31 11:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 33853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33853&action=edit
try to fix leak
The rightmost node is not necessarily a leaf, so set _M_nodes to
_M_rightmost()->_M_left if that exists.
Also simplify the constructor as it only needs one argument.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
2014-10-31 9:45 ` [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment redi at gcc dot gnu.org
2014-10-31 11:46 ` redi at gcc dot gnu.org
@ 2014-10-31 12:53 ` redi at gcc dot gnu.org
2014-10-31 13:40 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-31 12:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Does the same problem still exist in _M_extract?
This loop moves _M_nodes to the rightmost node again:
while (_M_nodes->_M_right)
_M_nodes = _M_nodes->_M_right;
Can that node have an _M_left child?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
` (2 preceding siblings ...)
2014-10-31 12:53 ` redi at gcc dot gnu.org
@ 2014-10-31 13:40 ` redi at gcc dot gnu.org
2014-10-31 14:09 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-31 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, it looks like we also need:
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -423,6 +423,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
while (_M_nodes->_M_right)
_M_nodes = _M_nodes->_M_right;
+ if (_M_nodes->_M_left)
+ _M_nodes = _M_nodes->_M_left;
}
}
else // __node is on the left.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
` (3 preceding siblings ...)
2014-10-31 13:40 ` redi at gcc dot gnu.org
@ 2014-10-31 14:09 ` redi at gcc dot gnu.org
2014-11-03 23:04 ` fdumont at gcc dot gnu.org
2014-11-05 19:16 ` fdumont at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2014-10-31 14:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This still leaks like a sieve without the second patch:
#include <set>
#include <random>
int main()
{
std::mt19937 rng;
std::uniform_int_distribution<int> d;
std::uniform_int_distribution<int>::param_type p{0, 100};
std::uniform_int_distribution<int>::param_type x{0, 1000};
for (int i = 0; i < 10; ++i)
{
std::set<int> l, r;
for (int n = d(rng, p); n > 0; --n)
{
int i = d(rng, x);
l.insert(i);
r.insert(i);
l = r;
}
}
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
` (4 preceding siblings ...)
2014-10-31 14:09 ` redi at gcc dot gnu.org
@ 2014-11-03 23:04 ` fdumont at gcc dot gnu.org
2014-11-05 19:16 ` fdumont at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: fdumont at gcc dot gnu.org @ 2014-11-03 23:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #7 from François Dumont <fdumont at gcc dot gnu.org> ---
Yes, looks like I had forgotten node with only a left child, too bad. My
initial plan was to use existing tree node algos in tree.cc but erase could not
be done without rebalancing which was useless for what we are doing in this
case.
So, do you take care of applying this or do you want me to submit a complete
patch on libstdc++ with your test ?
>From gcc-bugs-return-465676-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 03 23:30:19 2014
Return-Path: <gcc-bugs-return-465676-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29661 invoked by alias); 3 Nov 2014 23:30: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 29609 invoked by uid 48); 3 Nov 2014 23:30:16 -0000
From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug regression/61887] vect.exp UNRESOLVED tests
Date: Mon, 03 Nov 2014 23:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: regression
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thopre01 at gcc dot gnu.org
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: cc
Message-ID: <bug-61887-4-UEHQkuWRM1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61887-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61887-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-11/txt/msg00148.txt.bz2
Content-length: 473
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida887
thopre01 at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thopre01 at gcc dot gnu.org
--- Comment #3 from thopre01 at gcc dot gnu.org ---
"git grep slp testsuite" doesn't show me any directive looking for dump with a
slp extension so I guess this is solved?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
` (5 preceding siblings ...)
2014-11-03 23:04 ` fdumont at gcc dot gnu.org
@ 2014-11-05 19:16 ` fdumont at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: fdumont at gcc dot gnu.org @ 2014-11-05 19:16 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 7686 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
--- Comment #8 from François Dumont <fdumont at gcc dot gnu.org> ---
Author: fdumont
Date: Wed Nov 5 19:16:13 2014
New Revision: 217154
URL: https://gcc.gnu.org/viewcvs?rev=217154&root=gcc&view=rev
Log:
2014-11-04 François Dumont <fdumont@gcc.gnu.org>
Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/63698
* include/bits/stl_tree.h (_Reuse_or_alloc_node): Simplify constructor.
Always move to the left node if there is one.
* testsuite/23_containers/set/allocator/move_assign.cc (test04): New.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tree.h
trunk/libstdc++-v3/testsuite/23_containers/set/allocator/move_assign.cc
>From gcc-bugs-return-465831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 05 19:17:58 2014
Return-Path: <gcc-bugs-return-465831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28948 invoked by alias); 5 Nov 2014 19:17:58 -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 28914 invoked by uid 48); 5 Nov 2014 19:17:54 -0000
From: "fdumont at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
Date: Wed, 05 Nov 2014 19:17: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: fdumont 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-63698-4-WOUWtoEbUa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63698-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63698-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-11/txt/msg00303.txt.bz2
Content-length: 453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698
François Dumont <fdumont at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from François Dumont <fdumont at gcc dot gnu.org> ---
Now fixed on trunk
>From gcc-bugs-return-465832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 05 19:21:17 2014
Return-Path: <gcc-bugs-return-465832-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 508 invoked by alias); 5 Nov 2014 19:21:17 -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 474 invoked by uid 48); 5 Nov 2014 19:21:13 -0000
From: "joel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63755] New: m32c invalid asm generated in libgcc autoconf probe
Date: Wed, 05 Nov 2014 19:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joel at gcc dot gnu.org
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63755-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-11/txt/msg00304.txt.bz2
Content-length: 2830
https://gcc.gnu.org/bugzilla/show_bug.cgi?idc755
Bug ID: 63755
Summary: m32c invalid asm generated in libgcc autoconf probe
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id3899&actioníit
autoconf libgcc probe generating ICE
xgcc (GCC) 5.0.0 20141104 (experimental)
configure:: /users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/
-isystem
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include -mcpu=m32cm -c
--save-temps -fexceptions conftest.c >&5
conftest.c: In function 'foo':
conftest.c:19:1: error: insn does not satisfy its constraints:
}
^
(insn 50 38 23 (set (reg:SI 2 r1 [29])
(reg:SI 4 a0)) 99 {movsi_24}
(nil))
conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2946
0x87e623 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x87e64f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:121
0x659ba9 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2946
0x659c76 final(rtx_insn*, _IO_FILE*, int)
../../gcc/gcc/final.c:2076
0x65a61e rest_of_handle_final
../../gcc/gcc/final.c:4484
0x65a61e execute
../../gcc/gcc/final.c:4559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| #define SIZEOF_DOUBLE 8
| #define SIZEOF_LONG_DOUBLE 8
| #define HAVE_GETIPINFO 1
| /* end confdefs.h. */
|
| void bar ();
| void clean (int *);
| void foo ()
| {
| int i __attribute__ ((cleanup (clean)));
| bar();
| }
|
configure:4262: result: unknown
configure:4278: error: unable to detect exception model
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-11-05 19:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-31 9:15 [Bug libstdc++/63698] New: std::set leaks nodes on assignement adl at lrde dot epita.fr
2014-10-31 9:45 ` [Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment redi at gcc dot gnu.org
2014-10-31 11:46 ` redi at gcc dot gnu.org
2014-10-31 12:53 ` redi at gcc dot gnu.org
2014-10-31 13:40 ` redi at gcc dot gnu.org
2014-10-31 14:09 ` redi at gcc dot gnu.org
2014-11-03 23:04 ` fdumont at gcc dot gnu.org
2014-11-05 19:16 ` fdumont 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).