I am pleased to announce that the GCC Steering Committee has appointed
Maciej W. Rozycki as maintainer of the Vax backend in GCC.
Maciej, please update your listing in the MAINTAINERS file.
Good luck!
--joel
Sorry, I thought this was the libc list... :-)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Okt 25 2021, Florian Weimer wrote:
> Sorry, I don't understand. _Unwind_Find_FDE is a key part of the
> unwinder used for exception handling. It's definitely still in use.
Not on new platforms. See libc_cv_gcc_unwind_find_fde.
> But it looks like an internal implementation detail that was
* Andreas Schwab:
> On Okt 25 2021, Florian Weimer via Gcc wrote:
>
>> What should we do with _Unwind_Find_FDE and similar exported functions
>> that require types which are not currently defined in ?
>
> Aren't they legacy only?
Sorry, I don't understand. _Unwind_Find_FDE is a key part of the
u
On Okt 25 2021, Florian Weimer via Gcc wrote:
> What should we do with _Unwind_Find_FDE and similar exported functions
> that require types which are not currently defined in ?
Aren't they legacy only?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69
_Unwind_Find_FDE is exported as a public symbol on GNU/Linux, with a
default symbol version. But it's not part of the install
header, and its struct types are not namespace-clean for C++,
potentially leading to ODR violations.
What should we do with _Unwind_Find_FDE and similar exported function
Hello and good morning,
Recently I had the privilege of stumbling upon a few of the videos on youtube.
I really found them helpful, and learned quite a bit. I will say I probably
have to watch them a few more times to even begin to have a level of
understanding that everyone had years ago A
