https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #28 from Jonathan Wakely ---
(In reply to Thibaut M. from comment #27)
> A patch could be a least to avoid this `malloc` with some `#define` options?
That discussion belongs in PR 68606.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Thibaut M. changed:
What|Removed |Added
CC||dumoulin.thibaut at gmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #26 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #25 from Jonathan Wakely ---
> (In reply to rguent...@suse.de from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #25 from Jonathan Wakely ---
(In reply to rguent...@suse.de from comment #18)
> But again - where can you catch exceptions thrown from global
> initializers / destructors?
Within those global constructors/destructors themselves:
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #24 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #23)
> Is there a non-zeroed .bss section?
No.
> I think using dynamically allocated
> memory might be cheaper.
I very much doubt it.
> > That way "freeing" th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #23 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #22 from Jakub Jelinek ---
> Can't you use a .bss object for the initia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #22 from Jakub Jelinek ---
Can't you use a .bss object for the initial case, so you don't malloc anything
in the ctor unless user requests something larger than that?
That way "freeing" that would be handled in most cases. And I assu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #21 from Richard Biener ---
We can make it extra-safe but still deallocate in most common cases:
pool::~pool ()
{
__gnu_cxx::__scoped_lock sentry(emergency_mutex);
if (arena
&& arena == reinterpret_cast (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #20 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #18 from rguenther at suse dot de ---
On Tue, 27 Jan 2015, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #17 from Jonathan Wakely --- Ah, I
> assumed the lack of destructor was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #17 from Jonathan Wakely ---
Ah, I assumed the lack of destructor was intentional, so we can still deal with
exceptions while destroying globals. Otherwise an exception could try to
allocate from the pool after the destructor has run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #16 from Richard Biener ---
(In reply to Jonathan Wakely from comment #15)
> I think we need to get a suppression into valgrind:
>
> ==21268== Memcheck, a memory error detector
> ==21268== Copyright (C) 2002-2013, and GNU GPL'd, by J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #15 from Jonathan Wakely ---
I think we need to get a suppression into valgrind:
==21268== Memcheck, a memory error detector
==21268== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21268== Using Valgrind-3.9.0 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #13 from Richard Biener ---
Author: rguenth
Date: Thu Jan 22 09:21:48 2015
New Revision: 219988
URL: https://gcc.gnu.org/viewcvs?rev=219988&root=gcc&view=rev
Log:
2015-01-22 Richard Biener
PR libstdc++/64535
* libsupc++/e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #12 from Jonathan Wakely ---
(In reply to Richard Biener from comment #11)
> If reading 15.1.4 (Exception Handling / Throwing an exception) correctly
> then allocation happens in an unspecified way but according to 3.7.3.1
> which spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> Is the following required to work?
>
> #include
> #include
> #include
>
> struct large
> {
> char s[1024*1024*1024];
> };
>
> int main()
> {
> rlimit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #10 from rguenther at suse dot de ---
On Mon, 12 Jan 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
>
> --- Comment #9 from Jakub Jelinek ---
> If all allocations from the emergency pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #9 from Jakub Jelinek ---
If all allocations from the emergency pool are at least
sizeof(__cxa_refcounted_exception) long (or what is the minimum), then trying
to split the memory into smaller chunks (down to sizeof(free_entry)) might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Richard Biener changed:
What|Removed |Added
Attachment #34399|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #5 from Richard Biener ---
Created attachment 34399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34399&action=edit
patch fixing comment #4
This fixes the issue in comment #4 (it also decreases the emergency EH object
size).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #4 from Richard Biener ---
Is the following required to work?
#include
#include
#include
struct large
{
char s[1024*1024*1024];
};
int main()
{
rlimit lim;
lim.rlim_cur = 1024*1024*1024;
lim.rlim_max = 1024*1024*1024;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #3 from Richard Biener ---
Seeing that we have EH reference counted makes me think we should simply have
a single global std::bad_alloc EH to re-use?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #2 from Richard Biener ---
Also exceptions larger than std::bad_alloc should not eat from the emergency
buffer but instead cause std::bad_alloc to be thrown? Thus EMERGENCY_OBJ_SIZE
could be very much smaller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
--- Comment #1 from Richard Biener ---
It was pointed out that the pool is very large (even if reduced to 4 entries)
and thus undesirable for TLS (would be 4k then).
An alternative is to use a free list with variable size objects, initialized
to
28 matches
Mail list logo
