[Bug c++/98861] New: I want deterministic exceptions (Herbception)

[Bug c++/98861] New: I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

            Bug ID: 98861
           Summary: I want deterministic exceptions (Herbception)
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

The mailing list requires me to request the feature here. I put it here.
https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html
http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf

[Bug c++/98861] I want deterministic exceptions (Herbception)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-01-28
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #0)
> The mailing list requires me to request the feature here. I put it here.
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html

> "However, I desperately need that feature since current C++ exceptions
> are totally unusable."

Ridiculous claims like "totally unusable" aren't going to convince anybody.

> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf

This is just a proposal, one of many. It hasn't been approved by the committee
and is not without critics. It might be suitable to implement in a branch, as a
proof of concept, but most G++ developers are already busy working on things
that have actually been approved for inclusion in C++.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to cqwrteur from comment #0)
> > The mailing list requires me to request the feature here. I put it here.
> > https://www.mail-archive.com/gcc@gcc.gnu.org/msg94104.html
> 
> > "However, I desperately need that feature since current C++ exceptions
> > are totally unusable."
> 
> Ridiculous claims like "totally unusable" aren't going to convince anybody.
> 
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0709r4.pdf
> 
> This is just a proposal, one of many. It hasn't been approved by the
> committee and is not without critics. It might be suitable to implement in a
> branch, as a proof of concept, but most G++ developers are already busy
> working on things that have actually been approved for inclusion in C++.

How to start a branch? It can be an experimental branch, right?

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
> Ridiculous claims like "totally unusable" aren't going to convince anybody.

It is totally unusable. Binary bloat of runtime in bare-metal systems. Relying
on stdio.h even stdio.h is not freestanding.

C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is
basically a DDOS vulnerability.

The worst part is that vector would throw
std::length_error/std::bad_alloc/std::bad_array_length which are completely
useless tbh.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #3)
> > Ridiculous claims like "totally unusable" aren't going to convince anybody.
> 
> It is totally unusable. Binary bloat of runtime in bare-metal systems.
> Relying on stdio.h even stdio.h is not freestanding.
> 
> C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is
> basically a DDOS vulnerability.
> 
> The worst part is that vector would throw
> std::length_error/std::bad_alloc/std::bad_array_length which are completely
> useless tbh.

BTW. std::terminate() is not thread-safe which is terrible.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #4)
> (In reply to cqwrteur from comment #3)
> > > Ridiculous claims like "totally unusable" aren't going to convince anybody.
> > 
> > It is totally unusable. Binary bloat of runtime in bare-metal systems.
> > Relying on stdio.h even stdio.h is not freestanding.
> > 
> > C++ EH is thousands of times slower than syscalls on Linux. Any EH thrown is
> > basically a DDOS vulnerability.
> > 
> > The worst part is that vector would throw
> > std::length_error/std::bad_alloc/std::bad_array_length which are completely
> > useless tbh.
> 
> BTW. std::terminate() is not thread-safe which is terrible.

I ban C++ EH every day.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't think this is a useful bug report.  If/when the proposal gets accepted,
it will be useful to track who's working on it, but until then I see no point.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #7 from cqwrteur <unlvsur at live dot com> ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report.  If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.

I would like to work on it tbh. However, I do not know how to start this
branch.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #8 from cqwrteur <unlvsur at live dot com> ---
(In reply to Marek Polacek from comment #6)
> I don't think this is a useful bug report.  If/when the proposal gets
> accepted, it will be useful to track who's working on it, but until then I
> see no point.

Because current C++ exceptions are completely unusable for me. I suffer from it
every day. I desperately need to do this on my own.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #9 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
You can clone the gcc repo as explained here https://gcc.gnu.org/git.html and
then start your own local branch.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #3)
> Relying on stdio.h even stdio.h is not freestanding.

Nonsense.

(In reply to cqwrteur from comment #4)
> BTW. std::terminate() is not thread-safe which is terrible.

Nonsense.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
> 
> Nonsense.
> 
> (In reply to cqwrteur from comment #4)
> > BTW. std::terminate() is not thread-safe which is terrible.
> 
> Nonsense.

Functions without thread-safety are always terrible. Like all functions in
cctype. They should be avoided like plague.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #12 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to cqwrteur from comment #3)
> > Relying on stdio.h even stdio.h is not freestanding.
> 
> Nonsense.

stdio.h should not get included in any circumstances for EH. You are
implementing the operating system, but you need to enable EH by the standard
and EH relies on stdio. Chicken-egg problem.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #11)
> Functions without thread-safety are always terrible. Like all functions in
> cctype. They should be avoided like plague.

It's thread-safe though. What are you talking about?

(In reply to cqwrteur from comment #12)
> stdio.h should not get included in any circumstances for EH. You are
> implementing the operating system, but you need to enable EH by the standard
> and EH relies on stdio. Chicken-egg problem.

It doesn't depend on stdio though. What are you talking about?

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #14 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to cqwrteur from comment #11)
> > Functions without thread-safety are always terrible. Like all functions in
> > cctype. They should be avoided like plague.
> 
> It's thread-safe though. What are you talking about?

It calls std::abort() and std::abort() will close FILE* and FILE* might not be
thread-safe.

BTW std::terminate() is slow compared to compiler intrinsic like
__builtin_trap().

> (In reply to cqwrteur from comment #12)
> > stdio.h should not get included in any circumstances for EH. You are
> > implementing the operating system, but you need to enable EH by the standard
> > and EH relies on stdio. Chicken-egg problem.
> 
> It doesn't depend on stdio though. What are you talking about?

https://github.com/gcc-mirror/gcc/blob/e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/vterminate.cc#L93

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> > (In reply to cqwrteur from comment #12)
> > > stdio.h should not get included in any circumstances for EH. You are
> > > implementing the operating system, but you need to enable EH by the standard
> > > and EH relies on stdio. Chicken-egg problem.
> > 
> > It doesn't depend on stdio though. What are you talking about?
> 
> https://github.com/gcc-mirror/gcc/blob/
> e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/
> vterminate.cc#L93

Which is disabled in freestanding, and can be optionally disabled in hosted.

This is an OPTIONAL feature of libstdc++, not something that exception handling
intrinsically relies on. If you don't want it, you don't have to use it.

And if you're implementing the OS then you're using freestanding and it's
automatically disabled. Looks at line 27 in that file.

Once again you are talking out of your backside.

Stop wasting our time.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #16 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating system, but you need to enable EH by the standard
> > > > and EH relies on stdio. Chicken-egg problem.
> > > 
> > > It doesn't depend on stdio though. What are you talking about?
> > 
> > https://github.com/gcc-mirror/gcc/blob/
> > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/
> > vterminate.cc#L93
> 
> Which is disabled in freestanding, and can be optionally disabled in hosted.
> 
> This is an OPTIONAL feature of libstdc++, not something that exception
> handling intrinsically relies on. If you don't want it, you don't have to
> use it.
> 
> And if you're implementing the OS then you're using freestanding and it's
> automatically disabled. Looks at line 27 in that file.
> 
> Once again you are talking out of your backside.
> 
> Stop wasting our time.

That does not work in the real-world since your libstdc++'s freestanding header
never works correctly, (you get compilation errors). In reality, people just
use a "hosted toolchain" with GNU newlib. A "hosted version" of real
freestanding. Or you do not even have proper headers to run C++.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #17 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #15)
> > > (In reply to cqwrteur from comment #12)
> > > > stdio.h should not get included in any circumstances for EH. You are
> > > > implementing the operating system, but you need to enable EH by the standard
> > > > and EH relies on stdio. Chicken-egg problem.
> > > 
> > > It doesn't depend on stdio though. What are you talking about?
> > 
> > https://github.com/gcc-mirror/gcc/blob/
> > e11e5d3889f9e54c547efee50fa1b72b50f0f265/libstdc%2B%2B-v3/libsupc%2B%2B/
> > vterminate.cc#L93
> 
> Which is disabled in freestanding, and can be optionally disabled in hosted.
> 
> This is an OPTIONAL feature of libstdc++, not something that exception
> handling intrinsically relies on. If you don't want it, you don't have to
> use it.
> 
> And if you're implementing the OS then you're using freestanding and it's
> automatically disabled. Looks at line 27 in that file.
> 
> Once again you are talking out of your backside.
> 
> Stop wasting our time.

No one wants to tweak around compiler options since compiler options can always
break something tbh.

There is a reason why C++ is terrible in embedded systems and bare-metal
operating systems.

What Linus said was totally correct from a kernel dev perspective.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #17)
> No one wants to tweak around compiler options since compiler options can
> always break something tbh.

OK, go away and stop wasting our time then.

Write your own compiler or your own language and stop being a pain here.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #16)
> That does not work in the real-world since your libstdc++'s freestanding
> header never works correctly, (you get compilation errors).

Try reporting a bug about *that* next time (except don't, I don't want any more
stupidity from you).

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #20 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #19)
> (In reply to cqwrteur from comment #16)
> > That does not work in the real-world since your libstdc++'s freestanding
> > header never works correctly, (you get compilation errors).
> 
> Try reporting a bug about *that* next time (except don't, I don't want any
> more stupidity from you).

Let me be more clear.

1. Freestanding C++ in the current situation is very problematic. (You do not
have memcpy, you do not have std::move. You do not have std::forward. You do
not have std::addressof(). you do not have std::array.) However, you have an
exception handling support.

2. What's the point of reporting a bug when building libstdc++ with GNU newlib
just works much better and you have an entire hosted toolchain that will not
break compilation? The only problem is that you never enable EH.
I did report bugs before. However, it was not fixed. I am not going to try it
again tbh since newlib works just fine.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1105r0.html
Bare metal gcc 4.8 with newlib
undefined reference to "__exidx_end"
undefined reference to "__exidx_start"
undefined reference to "_exit"
undefined reference to "_sbrk"
undefined reference to "_kill"
undefined reference to "_getpid"
undefined reference to "_write"
undefined reference to "_close"
undefined reference to "_fstat"
undefined reference to "_isatty"
undefined reference to "_lseek"
undefined reference to "_read"

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #20)
> (In reply to Jonathan Wakely from comment #19)
> > (In reply to cqwrteur from comment #16)
> > > That does not work in the real-world since your libstdc++'s freestanding
> > > header never works correctly, (you get compilation errors).
> > 
> > Try reporting a bug about *that* next time (except don't, I don't want any
> > more stupidity from you).
> 
> Let me be more clear.


That would be a welcome change from your usual nonsense.

> 1. Freestanding C++ in the current situation is very problematic. (You do
> not have memcpy, you do not have std::move. You do not have std::forward.
> You do not have std::addressof(). you do not have std::array.) However, you
> have an exception handling support.

But no dependency on stdio.


> 2. What's the point of reporting a bug when building libstdc++ with GNU

So it can be fixed, duh.

> newlib just works much better and you have an entire hosted toolchain that
> will not break compilation? The only problem is that you never enable EH.
> I did report bugs before. However, it was not fixed. I am not going to try
> it again tbh since newlib works just fine.

Great. So build with --disable-libstdcxx-verbose as well and stop complaining
about a feature that other people find useful.

Maybe we should make that the default for --with-newlib builds. That might be a
useful improvement. More useful than your usual hyperbole and timewasting
anyway.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #22 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #20)
> 1. Freestanding C++ in the current situation is very problematic. (You do
> not have memcpy, you do not have std::move. You do not have std::forward.
> You do not have std::addressof().

Freestanding libstdc++ provides std::move, std::forward and std::addressof.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And memcpy must be provided as documented in the GCC documentation:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions.  GCC requires the
freestanding environment provide @code{memcpy}, @code{memmove},
@code{memset} and @code{memcmp}.
Finally, if @code{__builtin_trap} is used, and the target does
not implement the @code{trap} pattern, then GCC emits a call
to @code{abort}.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #24 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to cqwrteur from comment #20)
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::move. You do not have std::forward.
> > You do not have std::addressof().
> 
> Freestanding libstdc++ provides std::move, std::forward and std::addressof.

But that is actually not standard compliant. You may end up with another
toolchain that does not provide those facilities and you have troubles now.

The only option is to use newlib basically and that is why newlib is nowadays
the standard libc for embedded systems.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #25 from cqwrteur <unlvsur at live dot com> ---
> > 1. Freestanding C++ in the current situation is very problematic. (You do
> > not have memcpy, you do not have std::move. You do not have std::forward.
> > You do not have std::addressof(). you do not have std::array.) However, you
> > have an exception handling support.
> 
> But no dependency on stdio.

That does not mean it has no dependency. It depends on malloc/free which is
something you cannot avoid at all.

BTW, there are other issues with the implementation EH unwinder, it walks stack
twice for just more debugging information. Guess what is the information
consumed for? They output to stdio lol.

Your termination with multiple fputs calls also has issues even in a hosted
environment. Because it is not process-safe. When multiple processes throw eh
at the same time, they end up corrupting log files. (I did see that when i was
doing testing on the burden of multiple process TCP servers.) I guess changing
that to writev(2) might solve part of the problems but writev(2) does not
guarantee process safety for console or other I/O devices.
> 
> > 2. What's the point of reporting a bug when building libstdc++ with GNU
> 
> So it can be fixed, duh.
> 
> > newlib just works much better and you have an entire hosted toolchain that
> > will not break compilation? The only problem is that you never enable EH.
> > I did report bugs before. However, it was not fixed. I am not going to try
> > it again tbh since newlib works just fine.
> 
> Great. So build with --disable-libstdcxx-verbose as well and stop
> complaining about a feature that other people find useful.
> 
> Maybe we should make that the default for --with-newlib builds. That might
> be a useful improvement. More useful than your usual hyperbole and
> timewasting anyway.

I mean you can try to fix it a little. However, it breaks ABI. The effort does
not worth the cost.

More fundamental issues like binary bloat would never get fixed. Unfortunately,
the C++ compiler does not remove dead virtual functions. The entire C++
exceptions are built on virtual function calls. That stuff all add bloat you do
not want. Recently I just remove one virtual method of EH and the binary size
reduces 50KB for hello world.

If the exceptions are just designed for termination, it is nowhere better than
killing the process and restarted it again. (With __builtin_trap() you even get
higher performance than EH in the happy path because it reduces the burden of
CPU instruction cache)

For servers hosted on the internet, using EH is a disaster since it is
basically DDOS. The attacker can inject invalid input to make the process keep
throwing EH which ends up crashing. (There are security papers talking about
that. I can even show you). EH does not work for cryptography either since
cryptography requires deterministic. Any gap between timing can be a
side-channel.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #24)
> (In reply to Jonathan Wakely from comment #22)
> > (In reply to cqwrteur from comment #20)
> > > 1. Freestanding C++ in the current situation is very problematic. (You do
> > > not have memcpy, you do not have std::move. You do not have std::forward.
> > > You do not have std::addressof().
> > 
> > Freestanding libstdc++ provides std::move, std::forward and std::addressof.
> 
> But that is actually not standard compliant.

I think what you mean is it's not portable and strictly compliant code can't
rely on it.

It's is standard compliant for our freestanding mode to provide more than the
minimum required.

But portable code can't rely on deterministict exceptions either, yet you
insist that it's essential and you can't live without it. It seems you're quite
happy to rely on non-standard things when it suits you, but when it doesn't
it's completely unusable. Because you're a timewaster.

(In reply to cqwrteur from comment #25)
> I mean you can try to fix it a little. However, it breaks ABI.

So do deterministic exceptions.

Please go away and write your own compiler or language.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #27 from cqwrteur <unlvsur at live dot com> ---
> But portable code can't rely on deterministict exceptions either, yet you
> insist that it's essential and you can't live without it. It seems you're
> quite happy to rely on non-standard things when it suits you, but when it
> doesn't it's completely unusable. Because you're a timewaster.

It will be portable when it is a part of the C++ standard.

> (In reply to cqwrteur from comment #25)
> > I mean you can try to fix it a little. However, it breaks ABI.
> 
> So do deterministic exceptions.

It does not. No existing code will be broken because of deterministic
exceptions.

> Please go away and write your own compiler or language.

Rust folks did that. Are you happy with it?

I have no interest in writing my own compiler or language. I am more interested
in how to fixing existing things. I was a lover of C++ EH and I completely hate
C++ exceptions when I understand the ugliness beneath it. That is why
deterministic exceptions are important.

Same with C++ iostream, they need to be replaced with something else too.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #28 from cqwrteur <unlvsur at live dot com> ---
(In reply to cqwrteur from comment #27)
> > But portable code can't rely on deterministict exceptions either, yet you
> > insist that it's essential and you can't live without it. It seems you're
> > quite happy to rely on non-standard things when it suits you, but when it
> > doesn't it's completely unusable. Because you're a timewaster.
> 
> It will be portable when it is a part of the C++ standard.
> 
> > (In reply to cqwrteur from comment #25)
> > > I mean you can try to fix it a little. However, it breaks ABI.
> > 
> > So do deterministic exceptions.
> 
> It does not. No existing code will be broken because of deterministic
> exceptions.
>  
> > Please go away and write your own compiler or language.
> 
> Rust folks did that. Are you happy with it?
> 
> I have no interest in writing my own compiler or language. I am more
> interested in how to fixing existing things. I was a lover of C++ EH and I
> completely hate C++ exceptions when I understand the ugliness beneath it.
> That is why deterministic exceptions are important.
> 
> Same with C++ iostream, they need to be replaced with something else too.

That is why Herb Sutter said "digging the hole we already jumped into". Those
fixing makes nonsense, to be honest.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #29 from cqwrteur <unlvsur at live dot com> ---
(In reply to Jakub Jelinek from comment #23)
> And memcpy must be provided as documented in the GCC documentation:
> Most of the compiler support routines used by GCC are present in
> @file{libgcc}, but there are a few exceptions.  GCC requires the
> freestanding environment provide @code{memcpy}, @code{memmove},
> @code{memset} and @code{memcmp}.
> Finally, if @code{__builtin_trap} is used, and the target does
> not implement the @code{trap} pattern, then GCC emits a call
> to @code{abort}.

I am sure I did not understand anything wrong. The rule is simple, if you use
gcc, you must use libgcc. libgcc provides those facilities.

https://wiki.osdev.org/Libgcc

__builtin_trap() is always faster than std::terminate(), even it actually emits
a call to std::abort(), because std::terminate() requires atomic to sync the
terminate_handler. The problem with std::terminate() is that it does not work
like operator new where it is weak alias. You still get bloat and dependency to
std::abort() even you are using set_terminate_handle().

if we are using __builtin_trap() on platforms like x86_64, they emit ud
instructions and use that to terminate is fast and avoid dependency on libc,
(particularly we mean glibc here.)

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

--- Comment #30 from cqwrteur <unlvsur at live dot com> ---
> Great. So build with --disable-libstdcxx-verbose as well and stop
> complaining about a feature that other people find useful.

But even GCC bootstraps itself with EH, RTTI disabled (of course you are not
allowed to use iostream either). How could you convince other people they are
actually useful?

They are broken tbh.

[Bug c++/98861] I want deterministic exceptions (Herbception)

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |NEW

[Bug c++/98861] I want deterministic exceptions (Herbception)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98861

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #31 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
.