Re: performance of exception handling

[Thomas Neumann via Gcc]

> 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 that the other one wouldn't.

to make this discussion a bit less abstract I have implemented a
prototype: https://pastebin.com/KtrPhci2
It is not perfect yet, for example frame de-registration is suboptimal,
but it allows us to speak about an actual implementation with real
performance numbers.

To give some numbers I take my silly example from
https://repl.it/repls/DeliriousPrivateProfiler
with 6 * 1,000,000 function calls, where half of the functions throw,
and I execute it either single threaded or multi-threaded (with 6
threads) on a i7-6800K. Note that the effects are even more dramatic on
larger machines.
The "old" implementation is gcc 9.3., the "new" implementation is gcc
git with the patch linked above. (Note that you have to both use the
patched gcc and use LD_LIBRARY_PATH or similar to force the new libgcc
when repeating the experiment).

The execution times are:

old approach, single threaded: 4.3s
old approach, multi threaded: 6.5s
new approach, single threaded: 3.9s
new approach, multi threaded: 0.7s

This is faster even when single threaded, and it is dramatically faster
when using multiple threads. On machines where atomics are supported
raising an exception no longer uses a global mutex (except for the first
exception after new exception frames were added), and thus exception
processing scales nicely with the threaded count. The code also handles
the out-of-memory condition, falling back to linear search in that case
(just as the old code).

Of course this needs more polishing and testing, but would something
like this be acceptable for gcc? It makes exceptions much more useful in
multi-threaded applications.

Thomas

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

[Maciej W. Rozycki]

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. 
, 
.

  Maciej

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

[Jonathan Wakely via Gcc]

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 only Windows, some don't have
> > time to deal with the compilation (the whole toolchain takes around an
> > hour here, but this excludes the time to prepare the script that builds
> > it), some other consider the toolchain provided by MCU vendor (or by
> > ARM) as "tested to work correctly" so they don't want to replace that
> > with their custom built solution, and so on, and so on...
>
> There is no one-size-fits-all solution that gives everybody their
> ideal set of defaults, so we provide configuration options to tune
> things for your needs. Complaining that you have to rebuild things to
> get different defaults seems silly. Would you prefer we don't offer
> the options at all?

And I also never said that every user should rebuild the toolchain.
The options can be used by vendors providing a toolchain for their
hardware, if the verbose handler (or exceptions in general!) are not
appropriate for their users. Just because something isn't the default,
doesn't mean every user needs to change it themselves.

And if writing a script and waiting an hour is too much effort to
reduce unwanted overhead, then I guess that overhead isn't such a big
deal anyway.

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

[Jonathan Wakely via Gcc]

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 - that all the problems are related to
> specific implementation and thus can be easily fixed


I didn't say anything about it being easy to fix.

I'm just trying to stop misinformation about std::terminate requiring
string handling or I/O, which isn't true for C++ in general, and isn't
even true for libstdc++ because it's configurable. If you want a
smaller EH runtime, that's already possible with libstdc++. Could it
be even smaller? Yes, probably, but we need bug reports or concrete
suggestions, not outdated or misleading claims about optional
properties of the libstdc++ runtime.


> - is the same for
> years and yet the problem is still there (; I guess that if this could
> be easily fixed, then it would be done years ago. Along with the
> performance and non-deterministic execution issues...

Nobody said it can easily be fixed though.

> > If the comments above are referring to the libstdc++ verbose
> > terminate
> > handler, that's configurable. Configuring GCC with
> > --disable-libstdcxx-verbose will disable that, and so will building
> > libstdc++ with -fno-exceptions. That was fixed years ago.
>
> True, sorry for the confusion, indeed I was talking about verbose
> terminate handler. I check the state of C++ exceptions for MCUs only
> once every few years, so that's why I got that mixed with
> std::terminate(). I use my custom compilation with disabled exceptions
> (toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this
> works perfectly fine.

It's been a few years since we changed anything, because disabling the
verbose handler solved one of the biggest issues.

> 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 only Windows, some don't have
> time to deal with the compilation (the whole toolchain takes around an
> hour here, but this excludes the time to prepare the script that builds
> it), some other consider the toolchain provided by MCU vendor (or by
> ARM) as "tested to work correctly" so they don't want to replace that
> with their custom built solution, and so on, and so on...

There is no one-size-fits-all solution that gives everybody their
ideal set of defaults, so we provide configuration options to tune
things for your needs. Complaining that you have to rebuild things to
get different defaults seems silly. Would you prefer we don't offer
the options at all?

If you have concrete suggestions for improvements or can identify
places we can improve, I'd like to hear them. If you just want to
complain about C++ exceptions, that's not very helpful.

Re: Help porting a plugin to more recent GCC

[David Malcolm via 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
> Wiki[1]
> to get in touch if one has any questions concerning developing
> plugins,
> so I'll try this and see if anybody would be so kind to give me a
> little
> guidance!
> 
> The plugin is GCC-Bridge of the Renjin project which has been
> discussed
> on this mailing list before[2]. It is part of an effort to create a
> JVM
> runtime for the R language. The GCC-Brigde plugin compiles Gimple to
> JVM
> bytecode to make that runtime possible. The original project lives
> here[3], however, I have created a fork[4] that concentrates on just
> the part that compiles C code to JVM bytecode. The plugin is
> currently
> written using the plugin API of GCC 4.7. Since 4.7 is not available
> on
> my current Ubuntu-based system any longer, I would like to migrate to
> a
> newer version. 4.8 is available on my system, so migrating to that
> version would suffice as a first step. I tried that, however
> compilation fails using gcc-4.8 and after some reading the docs and
> going through the GCC source code history it seems that 4.7 to 4.8
> was
> a rather big evolution.
> 
> If anyone wants to take a look at the error messages, I created a
> branch[5] that has everything set up so that you can just run the
> compiler and see what happens; the README[6] file contains the
> necessary compilation instructions. It also shows the current output
> of
> gcc-4.8 and the error messages it produces. The plugin consists of a
> single file[7]. It seems that a global variable called
> "varpool_nodes"
> is not available anymore and also the members of the struct
> varpool_node changed.

4.8 is rather ancient at this point.

Looking at gcc/ChangeLog-2012 I see a change 

  2012-04-16  Jan Hubicka  

in which, if I'm reading it right, varpool_nodes was removed in favor
of a symtab_nodes function (combining both variables and callgraph
nodes).  In later releases (I think) they got encapsulated into a
symbtab class.

There's also a FOR_EACH_VARIABLE macro that might give you what you
need.

>  I haven't been able to figure out a way to
> traverse the Gimple tree and data structures the way the plugin did
> with the older API. If anyone here is familiar with the changes to
> the
> plugin API from 4.7 to 4.8, maybe you have a few hints for me?
> Pointers
> to a different plugin that went through a migration from 4.7 to a
> newer
> version could also be very very helpful. Any ideas?

My gcc-python-plugin attempts to support gcc 4.6 onwards from one
source tree, so has a lot of nasty compatibility cruft:
  https://github.com/davidmalcolm/gcc-python-plugin
which might be helpful (or might not).

Hope this is constructive
Dave


> 
> Thank you!
> Sebastian
> 
> [1] https://gcc.gnu.org/wiki/plugins
> [2] https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg4.html
> [3] https://github.com/bedatadriven/renjin/
> [4] https://github.com/mobanisto/gcc-bridge
> [5] https://github.com/mobanisto/gcc-bridge/tree/gcc-4.8
> [6] https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/README.md
> [7] 
> https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/compiler/src/main/resources/org/renjin/gcc/plugin.c
> 

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

[Freddie Chopin]

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 thus can be easily fixed - is the same for
years and yet the problem is still there (; I guess that if this could
be easily fixed, then it would be done years ago. Along with the
performance and non-deterministic execution issues...

> If the comments above are referring to the libstdc++ verbose
> terminate
> handler, that's configurable. Configuring GCC with
> --disable-libstdcxx-verbose will disable that, and so will building
> libstdc++ with -fno-exceptions. That was fixed years ago.

True, sorry for the confusion, indeed I was talking about verbose
terminate handler. I check the state of C++ exceptions for MCUs only
once every few years, so that's why I got that mixed with
std::terminate(). I use my custom compilation with disabled exceptions
(toolchain & libstdc++ built with -fno-exceptions -fno-rtti) and this
works perfectly fine.

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 only Windows, some don't have
time to deal with the compilation (the whole toolchain takes around an
hour here, but this excludes the time to prepare the script that builds
it), some other consider the toolchain provided by MCU vendor (or by
ARM) as "tested to work correctly" so they don't want to replace that
with their custom built solution, and so on, and so on...

Regards,
FCh

Re: rsync access to mailing list archives

[Rainer Orth]

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 new.

excellent.  Thanks a lot for the blazingly fast solution.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: rsync access to mailing list archives

[Frank Ch. Eigler via Gcc]

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

[Richard Biener via Gcc]

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 memory statements local
to a function
with a _single_ underlying variable (.MEM) and thus only one SSA name
live at the same
time.  It can be used to quickly traverse stores via use->def chains
and loads inbetween
two stores via immediate uses.

Richard.

> ---Original---
> From: "Richard Biener"
> Date: Tue, May 12, 2020 22:02 PM
> To: "易会战";
> Cc: "gcc";
> Subject: 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_VAR. But for a virtual DEFAULT DEF, I cannot get it, 
> > SSA_NAME_VAR return a identifier named .MEM. I cannot find which variable 
> > related to the default definition. Why and how I should find the related 
> > variable?
> >
> >
> > By the way , I give my current work,  I wish find a MEM_REF refer to 
> > global/heap memory or local stack. I try my best to get a correct memory 
> > type. Since MEM_REF have a base address, which is often a ssa name. Athough 
> > it is not virtual ssa name. But I find just check ssa name data flow is not 
> > enough to get the info.
> > For example, a malloc function allocate some heap memory and record the 
> > address in a global ptr. On gimple ssa IR, the malloc function return a 
> > address assigned to a ssa name , then ssa name assign the value to the 
> > global ptr. When i check ssa name defined by the global ptr, I donot know 
> > if the ptr point to global memory or local memory.
> > Please see the gimple code:
> > _2 = malloc()
> > ptr = _2
> > _3 = ptr
> > MEM_REF[BASE _3]
> > I wish get _3  is a address pointing to global memory. But just from 
> > _3=ptr, cannot judge it. 
> > I wish memory SSA can help solve the problem.
>
> memory SSA will not solve this problem.  You can instead query
> points-to information
> on _3 for example by calling ptr_deref_may_alias_global_p (_3) which 
> internally
> looks at SSA_NAME_PTR_INFO which contains the solution of the
> points-to computation.
>
> Richard.
>
> >
> > Or gcc gives the info at other pass? wish get some advice. Thanks a lot.

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

[易会战 via Gcc]

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

[Richard Biener via Gcc]

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_VAR. But for a virtual DEFAULT DEF, I cannot get it, 
> SSA_NAME_VAR return a identifier named .MEM. I cannot find which variable 
> related to the default definition. Why and how I should find the related 
> variable?
>
>
> By the way , I give my current work,  I wish find a MEM_REF refer to 
> global/heap memory or local stack. I try my best to get a correct memory 
> type. Since MEM_REF have a base address, which is often a ssa name. Athough 
> it is not virtual ssa name. But I find just check ssa name data flow is not 
> enough to get the info.
> For example, a malloc function allocate some heap memory and record the 
> address in a global ptr. On gimple ssa IR, the malloc function return a 
> address assigned to a ssa name , then ssa name assign the value to the global 
> ptr. When i check ssa name defined by the global ptr, I donot know if the ptr 
> point to global memory or local memory.
> Please see the gimple code:
> _2 = malloc()
> ptr = _2
> _3 = ptr
> MEM_REF[BASE _3]
> I wish get _3  is a address pointing to global memory. But just from 
> _3=ptr, cannot judge it. 
> I wish memory SSA can help solve the problem.

memory SSA will not solve this problem.  You can instead query
points-to information
on _3 for example by calling ptr_deref_may_alias_global_p (_3) which internally
looks at SSA_NAME_PTR_INFO which contains the solution of the
points-to computation.

Richard.

>
> Or gcc gives the info at other pass? wish get some advice. Thanks a lot.

Re: size of exception handling

[Moritz Strübe]

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.

Why?  Have you simulated the code size changes?


No, but I read a lot of C/ C++ generated assembler (Mainly ARM and 
without Exceptions. :) ).



I actually ran some
experiments.


Sweet. Would you mind sharing the results?

Morty

--
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

how to find variable related to a virtual ssa name

[易会战 via Gcc]

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_VAR 
return a identifier named .MEM. I cannot find which variable related to the 
default definition. Why and how I should find the related variable?


By the way , I give my current work,  I wish find a MEM_REF refer to 
global/heap memory or local stack. I try my best to get a correct memory type. 
Since MEM_REF have a base address, which is often a ssa name. Athough it is not 
virtual ssa name. But I find just check ssa name data flow is not enough to get 
the info.
For example, a malloc function allocate some heap memory and record the address 
in a global ptr. On gimple ssa IR, the malloc function return a address 
assigned to a ssa name , then ssa name assign the value to the global ptr. When 
i check ssa name defined by the global ptr, I donot know if the ptr point to 
global memory or local memory.
Please see the gimple code:
_2 = malloc()
ptr = _2
_3 = ptr
MEM_REF[BASE _3]
I wish get _3  is a address pointing to global memory. But just from 
_3=ptr, cannot judge it. 
I wish memory SSA can help solve the problem.


Or gcc gives the info at other pass? wish get some advice. Thanks a lot.

rsync access to mailing list archives

[Rainer Orth]

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,
too?  The incremental update possibility has been quite convenient for
me: I've used it to keep a local copy of the gcc-testresults list which
allowed for detailed queries of testsuite failures across the whole
range of reported targets.

Currently, there's only the compressed archive of each month, which for
one isn't one file per message and cannot be re-transferred
incrementally.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: size of exception handling

[Florian Weimer via Gcc]

* 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 simulated the code size changes?  I actually ran some
experiments.

> Exceptions are critical errors you need to handle anyway. Thus the
> code size should not increase as the error-handling code should
> already be there.  I can really recommend Herb's talk:
> https://www.youtube.com/watch?v=ARYP83yNAWk , where also talks about
> reducing RTTI overhead and making the C++-lib mostly exception free.

I think the proponents generally underestimate how many functions would
need to change their signature so that they can propagate errors using
the new mechanism.  This leads to very optimistic estimations on size
impact.

> In that talk he mentions that it would be possible using some CPU-Bit
> to return the state.

That's quite hard for us because of the stack protector.  It's unclear
if using the flag is actually beneficial from a code site perspective.
Obviously it depends on the ration between functions and call sites.

Thanks,
Florian

Re: size of exception handling

[Moritz Strübe]

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 agree with Freddie: 
Exceptions are critical errors you need to handle anyway. Thus the code 
size should not increase as the error-handling code should already be 
there.
I can really recommend Herb's talk: 
https://www.youtube.com/watch?v=ARYP83yNAWk ,  where also talks about 
reducing RTTI overhead and making the C++-lib mostly exception free.
In that talk he mentions that it would be possible using some CPU-Bit to 
return the state. This could result in adding a single instruction for 
each call (ret/jmp if bit is set) and maybe a second to clear that flag. 
Considering that you normally have to use at least an extra byte to pass 
this information,  which then needs to be evaluated, using 
Herbcexceptions might actually result in smaller code than using manual 
error handling. You still need run-time type information for catching, 
but I'm sure that there are solutions for that, too (e.g. Herb's 
solution from the talk *).


Cheers
Morty


* Alternatively it could be possible to only add type information that 
is necessary for catching and only for types that can actually be thrown 
(as far as I can see, all exceptions types must be known at link-time, 
as they are constructed by the throw-expression).



--
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

Re: size of exception handling

[Jonathan Wakely via Gcc]

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.

There is no string handling code in std::terminate:

namespace std
{
  typedef void (*terminate_handler) ();
  void terminate() _GLIBCXX_USE_NOEXCEPT __attribute__ ((__noreturn__));
}

void
__cxxabiv1::__terminate (std::terminate_handler handler) throw ()
{
  __try
{
  handler ();
  std::abort ();
}
  __catch(...)
{ std::abort (); }
}

void
std::terminate () throw()
{
  __terminate (get_terminate ());
}

Please clarify what you're talking about.

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

[Jonathan Wakely via Gcc]

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 about 20 kB of ROM
> (by overriding a lot of string formatting code and overriding
> std::terminate()),

You're talking about C++ exceptions in general, but the problems you
mention seems to be issues with specific implementation properties.

If the comments above are referring to the libstdc++ verbose terminate
handler, that's configurable. Configuring GCC with
--disable-libstdcxx-verbose will disable that, and so will building
libstdc++ with -fno-exceptions. That was fixed years ago.

If there are remaining problems where I/O and string routines get
dragged in without exceptions and the verbose terminate handler,
please report bugs against libstdc++. I would expect heroics to be
needed for a tiny footprint, but it should be possible to get a small
footprint just by rebuilding with the right options and flags.

Re: size of exception handling

[Freddie Chopin]

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 be implemented someday.
> 
> 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%?

As I understand the proposal, it would basically boil down to returning
something like std::pair where XXX is what you return
explicitly in the code. Or sth like returning std::variant<> or
std::optional<>. I use these approaches in my own code all the time
(mostly std::pair, as it's the simplest one). The rest of the
proposal seems to be syntax sugar for catching this "HerbCeption" and
so on. As my code basically does the same now, I guess the increase for
me would be ~0%.

I perfectly understand that error handling has some non-zero cost and
the only way to avoid it is to completely ignore the errors (; But it
seems to me that what is proposed there is really very cheap and very
fast. As long as the committee will drop std::string and such from
std::error_code (;

With current C++ exceptions the increase is not very proportional to
the size of the rest of the application. It's more like a one-time ~60
kB increase, even if the application without it would be 5 kB total. In
a huge application the increase may be less noticeable, as parts of the
pulled code may be used anyway by the app (things like dynamic
allocation, fprintf() and so on), but this is still ~25% of total
available ROM size.

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. The proposal by Herb seems to be more reasonable
in this regard - the amount of extra code generated under the hood will
probably be proportional to the amount of code involved and actually
similar to what C programmers do manually for decades.

Regards,
FCh

Re: size of exception handling

[Florian Weimer via Gcc]

* 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 different directions.

> That's why the proposal by Herb is a real surprise and I really hope
> it could be implemented someday.

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%?

> The numbers above are maybe a bit too strict. A typical ARM Cortex-M
> chip can have up to 2 MB of ROM and 512 kB of RAM, but I would say that
> usually it has around 128-256 kB of ROM and somewhere around 16-64 kB
> of RAM. 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 about 20 kB of ROM
> (by overriding a lot of string formatting code and overriding
> std::terminate()), but this is still too much for a feature you
> actually don't use.

It might still be interesting to contribute this somewhere.

Is there any effort to bring down the table sizes and reduce the
duplicated code in the cleanup paths?  In most cases, it seems that the
unwinder could actually run (the tail of) the successful return path and
call _Unwinded_Resume itself, rather than having the compiler duplicate
the cleanup code with an _Unwind_Resume at the end.

The code optimizations would likely be needed for the flag-return error
handling approach, too.

Thanks,
Florian

Re: Automatically generated ChangeLog files - PHASE 1

[Jakub Jelinek via Gcc]

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 reasonable error message
> when violated. The hook is based on [2] and the page also contains
> a fuzzy definition of what is supported. Cloning [2], one can also
> check what will be added to ChangeLog entries by:

I'd like to add, when testing in gcc-reposurgeon-8.git, please avoid
referencing non-testing PRs so that they won't be spammed, you can e.g. use
PR93218 which has been created for the testing during svn -> git conversion.

Jakub

Help porting a plugin to more recent GCC

[Sebastian Kürten]

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 plugins,
so I'll try this and see if anybody would be so kind to give me a little
guidance!

The plugin is GCC-Bridge of the Renjin project which has been discussed
on this mailing list before[2]. It is part of an effort to create a JVM
runtime for the R language. The GCC-Brigde plugin compiles Gimple to JVM
bytecode to make that runtime possible. The original project lives
here[3], however, I have created a fork[4] that concentrates on just
the part that compiles C code to JVM bytecode. The plugin is currently
written using the plugin API of GCC 4.7. Since 4.7 is not available on
my current Ubuntu-based system any longer, I would like to migrate to a
newer version. 4.8 is available on my system, so migrating to that
version would suffice as a first step. I tried that, however
compilation fails using gcc-4.8 and after some reading the docs and
going through the GCC source code history it seems that 4.7 to 4.8 was
a rather big evolution.

If anyone wants to take a look at the error messages, I created a
branch[5] that has everything set up so that you can just run the
compiler and see what happens; the README[6] file contains the
necessary compilation instructions. It also shows the current output of
gcc-4.8 and the error messages it produces. The plugin consists of a
single file[7]. It seems that a global variable called "varpool_nodes"
is not available anymore and also the members of the struct
varpool_node changed. I haven't been able to figure out a way to
traverse the Gimple tree and data structures the way the plugin did
with the older API. If anyone here is familiar with the changes to the
plugin API from 4.7 to 4.8, maybe you have a few hints for me? Pointers
to a different plugin that went through a migration from 4.7 to a newer
version could also be very very helpful. Any ideas?

Thank you!
Sebastian

[1] https://gcc.gnu.org/wiki/plugins
[2] https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg4.html
[3] https://github.com/bedatadriven/renjin/
[4] https://github.com/mobanisto/gcc-bridge
[5] https://github.com/mobanisto/gcc-bridge/tree/gcc-4.8
[6] https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/README.md
[7] 
https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/compiler/src/main/resources/org/renjin/gcc/plugin.c

Re: performance of exception handling

[Richard Sandiford]

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 originally proposed? Or give up due
> to the inertia of a large, grown system?

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 that the other one wouldn't.

Thanks,
Richard

Re: Automatically generated ChangeLog files - PHASE 1

[Martin Liška]

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 ([1]) and provides a reasonable error message
when violated. The hook is based on [2] and the page also contains
a fuzzy definition of what is supported. Cloning [2], one can also
check what will be added to ChangeLog entries by:

$ ./git_changelog.py /home/marxin/Programming/gcc-reposurgeon-8 
8a37df5e5cb2de8302f9412173103593ec53961e
-- gcc/ChangeLog --
2020-01-13  Martin Jambor  

 PR ipa/93223
 * ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
 NULL.
-- gcc/testsuite/ChangeLog --
2020-01-13  Martin Jambor  

 PR ipa/93223
 testsuite/
 * g++.dg/ipa/pr93223.C: New test.

(one needs [3] Python package for that)

We encourage people to test both the hook and the script. We hope we'll cover
majority of the used formats. I also support _not_ using DATESTAMP and committer
name, these can be automatically deduced from a commit. That will simplify 
workflow
as people won't have to adjust a message before pushing.

Unresolved questions:
- format of reverted patches
- what to do with backports

Here I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.
Doing that the commit messages will provide link to original commit and the 
script
can later append corresponding 'Backported ..' or 'Reverted' line.

For the possible issues or questions, please open a Github issue at [4].

Thoughts?
Martin

[1] https://github.com/marxin/git-hooks/tree/gcc-changelog
[2] https://github.com/marxin/gcc-changelog
[3] https://gitpython.readthedocs.io/en/stable/intro.html
[4] https://github.com/marxin/gcc-changelog/issues

Automatically generated ChangeLog files - PHASE 1

[Martin Liška]

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 page also contains
a fuzzy definition of what is supported. Cloning [2], one can also
check what will be added to ChangeLog entries by:

$ ./git_changelog.py /home/marxin/Programming/gcc-reposurgeon-8 
8a37df5e5cb2de8302f9412173103593ec53961e
-- gcc/ChangeLog --
2020-01-13  Martin Jambor  

PR ipa/93223
* ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
NULL.
-- gcc/testsuite/ChangeLog --
2020-01-13  Martin Jambor  

PR ipa/93223
testsuite/
* g++.dg/ipa/pr93223.C: New test.

(one needs [3] Python package for that)

We encourage people to test both the hook and the script. We hope we'll cover
majority of the used formats. I also support _not_ using DATESTAMP and committer
name, these can be automatically deduced from a commit. That will simplify 
workflow
as people won't have to adjust a message before pushing.

Unresolved questions:
- format of reverted patches
- what to do with backports

Here I suggest to use native 'git revert XYZ' and 'git cherry-pick -x XYZ'.
Doing that the commit messages will provide link to original commit and the 
script
can later append corresponding 'Backported ..' or 'Reverted' line.

For the possible issues or questions, please open a Github issue at [4].

Thoughts?
Martin

[1] https://github.com/marxin/git-hooks/tree/gcc-changelog
[2] https://github.com/marxin/gcc-changelog
[3] https://gitpython.readthedocs.io/en/stable/intro.html
[4] https://github.com/marxin/gcc-changelog/issues

 

Re: size of exception handling

[Florian Weimer via Gcc]

* 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 it is
>> unfortunate that many projects disable exceptions due to performance
>> concerns. And I think the performance problems can be solved.
>
> 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 something around 32k of program memory and 2K of
> ram. And even those running Linux often have around 32MB program
> memory and 8MB of RAM. Also most of these systems are very cost
> sensitive, so each byte matters. Therefore RTTI and exceptions are one
> of the main reasons why parts of the embedded community consider C++
> unusable: They do some experiments using C++ and the code size
> explodes.  And even if you know what you are doing and turn interrupts
> and RTTI off, adding a std::nothrow to every "new" to do decent error
> handling is pretty annoying. Not mentioning the parts of the C++
> library that don't provide exception-free error-handling.

The flag-return proposal has costs as well, especially if applied
verbatim without any additional language changes.  There won't be large
tables, but code size will increase across all non-leaf, noexcept(false)
functions.

My worry is that the overhead will be enough to deter embedded users,
and then we are stuck with a third error handling approach for C++.

Thanks,
Florian

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

[Oleg Endo]

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" libraries, but I the options they used for newlib
> don't suit my needs - this is "too minimized"). If you pass these two
> flags during compilation and linking of your own application, this
> disables these features only in your code. As libstdc++ is compiled
> with exceptions and RTTI enabled, ...

IMHO this is a conceptual fail of the whole concept of using pre-
compiled pre-installed libraries somewhere in the toolchain, in
particular for this kind of cross-compilation scenario.  Like you say,
when we set "exceptions off" it usually means for the whole embedded
app, and the whole embedded app usually means all the OS and runtime
libraries and everything, not just the user code.

One option is to not use the pre-compiled toolchain libstc++ but build
it from source (or use another c++ std lib of your choice), as part of
the whole project, with the desired project settings.


BTW, just to throw in my 2-cents into the "I'm using MCU" pool of
pain/joy ... in one of my projects I'm using STM32F051K6U6, 32 KB
flash, 8 KB RAM, running all C++ code with shared C++ RPC libraries to
communicate with other (bigger) devices.  Exceptions, RTTI, threads
have to be turned off and only the header-only things from the stdlib
can be used and no heap allocations.  Otherwise the thing doesn't fit. 
Don't feel like rewriting the whole thing either.  There are some
annoyances when turning off exceptions and RTTI which results in
increased code maintenance.  I'd definitely be good and highly
appreciated if there were any improvements in the area of exception
handling.

Cheers,
Oleg

Re: performance of exception handling

[Thomas Neumann via Gcc]

> 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 possible) memory.

note that I would not allocate at all in the unwinding path. I would
allocate memory when new frames are registered, but unwinding would be
without any allocations.

Of course there is a trade-off here. We could delay allocating the
lookup structures until the first exception occurs, in order to speed up
programs that never throw any exceptions. But that would effectively
force us to implement a "no memory" fallback, for exactly the reason you
gave, as something like bad_alloc might be the first exception that we
encounter.

Thomas

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

[Freddie Chopin]

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 something around 32k of program memory and 2K of ram. And even 
> those running Linux often have around 32MB program memory and 8MB of 
> RAM. Also most of these systems are very cost sensitive, so each
> byte 
> matters. Therefore RTTI and exceptions are one of the main reasons
> why 
> parts of the embedded community consider C++ unusable: They do some 
> experiments using C++ and the code size explodes.  And even if you
> know 
> what you are doing and turn interrupts and RTTI off, adding a 
> std::nothrow to every "new" to do decent error handling is pretty 
> annoying. Not mentioning the parts of the C++ library that don't
> provide 
> exception-free error-handling.
> 
> So yes, improving the performance is nice, but ISO C++ will still be 
> unusable for most computer systems: There are way more emdedded
> systems 
> with less than 32MB program memory out there than PCs, Servers and 
> mobile phones together.

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's why the proposal by Herb is a real surprise
and I really hope it could be implemented someday.

The numbers above are maybe a bit too strict. A typical ARM Cortex-M
chip can have up to 2 MB of ROM and 512 kB of RAM, but I would say that
usually it has around 128-256 kB of ROM and somewhere around 16-64 kB
of RAM. 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 about 20 kB of ROM
(by overriding a lot of string formatting code and overriding
std::terminate()), but this is still too much for a feature you
actually don't use.

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" libraries, but I the options they used for newlib
don't suit my needs - this is "too minimized"). If you pass these two
flags during compilation and linking of your own application, this
disables these features only in your code. As libstdc++ is compiled
with exceptions and RTTI enabled, they get pulled during link anyway,
bloating the binary size with a functionality you don't use and can't
use - every throw from the library ends up as std::teminate() anyway.
That's why the statement by Herb that C++ exceptions are never zero-
cost when not used is perfectly true.

The performance is also an issue. Article I've read sometime ago
mentioned that a trivial throw out of a single function takes about
7000-1 clock cycles until it is catched, which is unacceptable for
any real-time solution (normal return with error handling would take at
most a few dozen). But the size issue is a blocker for deep embedded,
then the performance and deterministic behaviour are only secondary
issues in such environment.

Regards,
FCh

Re: performance of exception handling

[Richard Biener via Gcc]

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
> handled it within libgcc, as I had originally proposed? Or give up due
> to the inertia of a large, grown system?
>
> Another concern is memory consumption. I wanted to store the FDE entries
> in a b-tree, which allows for fast lookup and low overhead
> synchronization. Memory wise that is not really worse than what we have
> today (the "linear" and "erratic" arrays). But the current code has a
> fallback for when it is unable to allocate these arrays, falling back to
> linear search. Is something like that required? It would make the code
> much more complicated (but I got from Moritz mail that some people
> really care about memory constrained situations).

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 possible) memory.

Richard.

> Thomas