Re: performance of exception handling

> Just echoing what David said really, but: if the libgcc changes > are expected to be portable beyond glibc, then the existence of > an alternative option for glibc shouldn't block the libgcc changes. > The two approaches aren't be mutually exclusive and each approach > would achieve something tha

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

On Sat, 9 May 2020, Eric Botcazou wrote: > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > > are still lying around. > > I think that the e200 support was never contributed upstream. Or rather, it wasn't accepted. Cf.

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

On Tue, 12 May 2020 at 23:39, Jonathan Wakely wrote: > On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: > > Anyway... If you have to recompile the toolchain, the problem is still > > there. Most of the people (like 99,666%) will not do that for various > > reasons. Some don't know how, some use o

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

On Tue, 12 May 2020, 21:57 Freddie Chopin, wrote: > > On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > > You're talking about C++ exceptions in general, but the problems you > > mention seems to be issues with specific implementation properties. > > Possibly true, but this argument - th

Re: Help porting a plugin to more recent GCC

On Tue, 2020-05-12 at 11:12 +0200, Sebastian Kürten wrote: > Hi everybody, > > I'm trying to adapt an existing, open source GCC plugin so that it > will > work with more recent versions of GCC (it is currently working with > 4.7 > only). During my research I came across your suggestion on the > Wi

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

On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote: > You're talking about C++ exceptions in general, but the problems you > mention seems to be issues with specific implementation properties. Possibly true, but this argument - that all the problems are related to specific implementation and

Re: rsync access to mailing list archives

Hi Frank, >> Would it be possible to provide this feature for the current archives, >> too? [...] > > rsync now makes available the master .mbox files for every mailing > list hosted on sourceware: > >rsync gcc.gnu.org::gcc-mbox > > This includes historical ezmlm era files as well as the

Re: rsync access to mailing list archives

Hi - > Would it be possible to provide this feature for the current archives, > too? [...] rsync now makes available the master .mbox files for every mailing list hosted on sourceware: rsync gcc.gnu.org::gcc-mbox This includes historical ezmlm era files as well as the new. - FChE

Re: how to find variable related to a virtual ssa name

On Tue, May 12, 2020 at 4:16 PM 易会战 wrote: > > thanks a lot. I will check your advice. > Can you give some explaination about memory ssa, and how to use it. I check > internal, cannot get it. Maybe you know some examples or some more materials. memory SSA in GCC is simply a SSA chain of all memo

Re: how to find variable related to a virtual ssa name

thanks a lot. I will check your advice. Can you give some explaination about memory ssa, and how to use it. I check internal, cannot get it. Maybe you know some examples or some more materials. ---Original--- From: "Richard Biener"

Re: how to find variable related to a virtual ssa name

On Tue, May 12, 2020 at 2:44 PM 易会战 via Gcc wrote: > > hi, I am working on gcc ssa name. For each function, we can traverse all > defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa name is default > definition for a symbol (check SSA_NAME_IS_DEFAULT_DEF) , I can get the > symbol by SSA_NAME_

Re: size of exception handling

Hey. Am 12.05.2020 um 13:29 schrieb Florian Weimer: Would you use it if switching from -fno-exceptions to this new approach resulted in an immediate 20% code size increase, without actually using the new error handling feature at all? What about 10%? I don't think that it will be that much. W

how to find variable related to a virtual ssa name

hi, I am working on gcc ssa name. For each function, we can traverse all defined ssa name by macro FOR_EACH_SSA_NAME. If a ssa name is default definition for a symbol (check SSA_NAME_IS_DEFAULT_DEF) , I can get the symbol by SSA_NAME_VAR. But for a virtual DEFAULT DEF, I cannot get it, SSA_NAME_

rsync access to mailing list archives

Before the sourcware upgrade, it was possible to incrementally copy the mailing list archives using rsync. This is still advertised on https://gcc.gnu.org/rsync.html but this only includes the pre-upgrade archives. Would it be possible to provide this feature for the current archives, t

Re: size of exception handling

* Moritz Strübe: >> Would you use it if switching from -fno-exceptions to this new >> approach resulted in an immediate 20% code size increase, without >> actually using the new error handling feature at all? What about >> 10%? > > I don't think that it will be that much. Why? Have you simulate

Re: size of exception handling

Am 12.05.2020 um 11:44 schrieb Freddie Chopin: Would you use it if switching from -fno-exceptions to this new approach resulted in an immediate 20% code size increase, without actually using the new error handling feature at all? What about 10%? I don't think that it will be that much. I ag

Re: size of exception handling

On Tue, 12 May 2020 at 11:48, Freddie Chopin wrote: > To summarize. Current C++ exceptions have very huge, mostly "one-time" > kind, cost on the size, even if not used at all by the user, mosly due > to std::terminate() and all the string handling code inside it, as well > as the unwind tables. Th

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

On Tue, 12 May 2020 at 09:17, Freddie Chopin wrote: > The problem with C++ exceptions is that even in the most > trivial of the programs and even if you don't explicitly > use/catch/throw them, they instantly eat around 60 kB of ROM and quite > a lot of RAM. With some hacking you can get down to ab

Re: size of exception handling

On Tue, 2020-05-12 at 11:16 +0200, Florian Weimer wrote: > That can only happen if the embedded people do not bother to show up > in > numbers. Of course the tools will move in different directions. True (; > > That's why the proposal by Herb is a real surprise and I really > > hope > > it could

Re: size of exception handling

* Freddie Chopin: > Very nice that Moritz finally mentioned it (; The world of deep > embedded is usually forgotten by all the language committees and people > who are in charge. That can only happen if the embedded people do not bother to show up in numbers. Of course the tools will move in dif

Re: Automatically generated ChangeLog files - PHASE 1

On Tue, May 12, 2020 at 11:05:58AM +0200, Martin Liška wrote: > Thanks to Jakub, we finally set up an experimental environment: > gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git > > The repository now contains a new pre-commit hook that validates > the git commit format ([1]) and provides a reason

Help porting a plugin to more recent GCC

Hi everybody, I'm trying to adapt an existing, open source GCC plugin so that it will work with more recent versions of GCC (it is currently working with 4.7 only). During my research I came across your suggestion on the Wiki[1] to get in touch if one has any questions concerning developing plugin

Re: performance of exception handling

Thomas Neumann via Gcc writes: >> 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 or

Re: Automatically generated ChangeLog files - PHASE 1

I'm also CCing gcc-patches and fortran ML. Martin On 5/12/20 11:05 AM, Martin Liška wrote: Hi. Thanks to Jakub, we finally set up an experimental environment: gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git The repository now contains a new pre-commit hook that validates the git commit format

Automatically generated ChangeLog files - PHASE 1

Hi. Thanks to Jakub, we finally set up an experimental environment: gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git The repository now contains a new pre-commit hook that validates the git commit format ([1]) and provides a reasonable error message when violated. The hook is based on [2] and the

Re: size of exception handling

* Moritz Strübe: > 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

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

On Tue, 2020-05-12 at 09:20 +0200, Freddie Chopin wrote: > > I actually have to build my own toolchain instead of the one provided > by ARM, because to really NOT use C++ exceptions, you have to recompile > the whole libstdc++ with `-fno-exceptions -fno-rtti` (yes, I know they > provide the "nano"

Re: performance of exception handling

> Some people use exceptions to propagate "low memory" up which > made me increase the size of the EH emergency pool (which is > used when malloc cannot even allocate the EH data itself) ... > > So yes, people care. There absolutely has to be a path in > unwinding that allocates no (as little as

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

On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote: > I just wanted to point out that Herbceptions do not only fix > performance > issues, but also code-size problems. While anything below 4GB of RAM > is > considered under-powered for a PC, typical deep embedded > environments > have someth

Re: performance of exception handling

On Tue, May 12, 2020 at 8:14 AM Thomas Neumann via Gcc wrote: > > > 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 > h