[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2014-02-16 Thread jackie.rosen at hushmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC|

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2012-07-30 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2007-06-13 Thread dannysmith at users dot sourceforge dot net
--- Comment #50 from dannysmith at users dot sourceforge dot net 2007-06-14 03:21 --- (In reply to comment #37) I think basically you are messed up untill Cygwin switches to dwarf2 exceptions. This is now (=gcc 4.3) possible by adding --disable-sjlj-exceptions to configure. Can we

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2005-05-12 Thread pinskia at gcc dot gnu dot org
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2005-05-12 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-12 14:54 --- If you used the non throw new, it would become faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-14 Thread ken dot duda at gmail dot com
--- Additional Comments From ken dot duda at gmail dot com 2004-11-14 17:03 --- Subject: Re: new/delete much slower than malloc/free because of sjlj exceptions Thanks, Paul. Let me know if I can help in any way. I appeneded the output of gcc -v. -Ken

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-14 Thread paulthomas2 at wanadoo dot fr
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-14 18:04 --- Subject: Re: new/delete much slower than malloc/free because of sjlj exceptions Ken, Did you miss the question? Paul (iii) gcc 4.0.0 20041010 (experimental) I get 0.62 and 0.59micro-sec/new This

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-14 Thread ken dot duda at gmail dot com
--- Additional Comments From ken dot duda at gmail dot com 2004-11-14 22:40 --- Subject: Re: new/delete much slower than malloc/free because of sjlj exceptions Did you miss the question? Umm, apparently I did.. the only thing I see in the bug log that looks like a question is this:

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-13 Thread paulthomas2 at wanadoo dot fr
--- Additional Comments From paulthomas2 at wanadoo dot fr 2004-11-13 11:02 --- Subject: Re: new/delete much slower than malloc/free because of sjlj exceptions Here's a test case for you... -Ken That's interesting Using your test case: (i) gcc 3.2 20020927 ( prerelease)

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-10 Thread pinskia at gcc dot gnu dot org
-- What|Removed |Added Summary|[3.3/3.4/4.0 Regression]|new/delete much slower than |new/delete much slower than |malloc/free because of sjlj

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-10 Thread ron_hylton at hotmail dot com
--- Additional Comments From ron_hylton at hotmail dot com 2004-11-10 16:20 --- (In reply to comment #40) Ron, can you please attach your testcase that shows the problem to this PR? This PR is a regression on cygwin because the speed is back with 3.2. This is the test case I was

[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions

2004-11-10 Thread kjd at duda dot org
--- Additional Comments From kjd at duda dot org 2004-11-10 17:05 --- (In reply to comment #40) Ron, can you please attach your testcase that shows the problem to this PR? This PR is a regression on cygwin because the speed is back with 3.2. Here's a test case for you... -Ken