Re: performance of exception handling

> Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate > implementation in GLIBC creates its own set of advantages and > disadvantages. so what should I do now? Should I try to move the lookup into GLIBC? Or handled it within libgcc, as I had originally proposed? Or give up due to the

MANPOWER (Employee) Solutions for GCC GNU ORG

Attn: HR Dept. (GCC GNU ORG) Dear Sir/Ma'am, We (S.A.Z Universal Links) are a dedicated ‘Recruitment and Staffing’ Company in the sense that we can staff for a range of different industries. We work in a strategically processed manner to help industries attain potential candidates. We ha

[arm] GCC validation: preferred way of running the testsuite?

Hi, As you may know, I've been running validations of GCC trunk in many configurations for Arm and Aarch64. I was recently trying to make some cleanup in the new Bfloat16, MVE, CDE, and ACLE tests because in several configurations I see 300-400 FAILs mainly in these areas, because of “testisms”

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: >> >> * David Edelsohn: >> >> > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc >> > wrote: >> > >> >> My current preferred solution is something that moves the entire code >> >> that locates the relevant FDE tabl

size of exception handling (Was: performance of exception handling)

Hey. Am 11.05.2020 um 15:59 schrieb Thomas Neumann via Gcc: In a way I am disagreeing with the paper, of course, in that I propose to make the existing exception mechanism faster instead of inventing a new exception mechanism. But what I agree on with P0709 is that it is unfortunate that many pr

Re: performance of exception handling

On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: > > * David Edelsohn: > > > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > > wrote: > > > >> My current preferred solution is something that moves the entire code > >> that locates the relevant FDE table into glibc. This is all th

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > wrote: > >> My current preferred solution is something that moves the entire code >> that locates the relevant FDE table into glibc. This is all the code in >> _Unwind_IteratePhdrCallback until the first read_encoded_v

Re: performance of exception handling

On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc wrote: > My current preferred solution is something that moves the entire code > that locates the relevant FDE table into glibc. This is all the code in > _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base > call. And

Re: performance of exception handling

* Thomas Neumann: >> Link: >> >> I'm not sure if your summary is correct. > > I was referring to Section 3.2, where Herb says: > > "We must remove all technical reasons for a C++ project to disable > exception handling (e.g., by compiler switch) or ban use of exceptions,

Re: performance of exception handling

> Link: > > I'm not sure if your summary is correct. I was referring to Section 3.2, where Herb says: "We must remove all technical reasons for a C++ project to disable exception handling (e.g., by compiler switch) or ban use of exceptions, in all or part of their proje

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, May 09, 2020 at 09:31:55AM +0100, Jonathan Wakely wrote: > If the bug is still present in supported versions (like gcc-8 or > gcc-9) but will never be fixed (like SPE ones) they might as well be > closed now as WONTFIX. Suggesting anything else will happen to them is > misleading. Yeah, I

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi! On Sat, May 09, 2020 at 01:45:20PM +0700, Arseny Solokha wrote: > > LRA has been supported by the rs6000 port since 2013 (01b1efaa1439), > > and made the default (and only!) option in 2017 (7a5cbf29beb2). Ah, the > > latter was slightly after the split, I see. Did powerpcspe never work > > w

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

* Segher Boessenkool: > I can't speak for Arseny of course, but the reason *I* want this is to > no longer see all those powerpcspe BZs in my powerpc queries -- nothing > ever changes to them, so it's just pointless distraction. Keeping them open might also lead to some users believing that there

Re: performance of exception handling

* Thomas Neumann via Gcc: > Currently, exception handling scales poorly due to global mutexes when > throwing. This can be seen with a small demo script here: > https://repl.it/repls/DeliriousPrivateProfiler > Using a thread count >1 is much slower than running single threaded. > This global locki

performance of exception handling

Hi, I want to improve the performance of C++ exception handling, and I would like to get some feedback on how to tackle that. Currently, exception handling scales poorly due to global mutexes when throwing. This can be seen with a small demo script here: https://repl.it/repls/DeliriousPrivateProf