Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Jason Merrill via Gcc-patches
On 9/23/22 10:12, Thomas Neumann wrote:     +static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution.  It seems that in_shutdown also could be declared outside the #ifdef and initialized as "false". sure, either is fine. Moving it outside the

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Thomas Neumann via Gcc-patches
Hi Iain, You might also want to include Rainer’s patch, AFAIR patches to fix bootstrap are allowed to proceed as an exception to the usual rules, I was not aware of that. I have pushed the patch below now (including Rainer's change), I will update the code if requested. Best Thomas

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Iain Sandoe via Gcc-patches
> On 26 Sep 2022, at 12:49, Thomas Neumann via Gcc-patches > wrote: > > Hi Claudiu, > >> This change prohibits compiling of ARC backend: >>> + gcc_assert (in_shutdown || ob); >> in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, >> while gcc_assert is outside of any ifdef.

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Claudiu Zissulescu Ianculescu via Gcc-patches
Thanks, I haven't observed it. Waiting for it, Claudiu On Mon, Sep 26, 2022 at 2:49 PM Thomas Neumann wrote: > > Hi Claudiu, > > > This change prohibits compiling of ARC backend: > > > >> + gcc_assert (in_shutdown || ob); > > > > in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Thomas Neumann via Gcc-patches
Hi Claudiu, This change prohibits compiling of ARC backend: + gcc_assert (in_shutdown || ob); in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, while gcc_assert is outside of any ifdef. Please can you revisit this line and change it accordingly. I have a patch ready, I am

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Claudiu Zissulescu Ianculescu via Gcc-patches
Hi Thomas, This change prohibits compiling of ARC backend: > + gcc_assert (in_shutdown || ob); in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined, while gcc_assert is outside of any ifdef. Please can you revisit this line and change it accordingly. Thanks, Claudiu

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Rainer Orth
Hi Jeff, >>> Thanks for the patch. I'll let you and Jason decide which style solution >>> is preferred. >> This also breaks bootstrap on Darwin at least, so an early solution would be >> welcome (the fix here allows bootstrap to continue, testing on-going). >> thanks, > > I'm using it in the

Re: [PATCH] Avoid depending on destructor order

2022-09-25 Thread Jeff Law via Gcc-patches
On 9/25/22 00:29, Iain Sandoe wrote: On 23 Sep 2022, at 15:30, David Edelsohn via Gcc-patches wrote: On Fri, Sep 23, 2022 at 10:12 AM Thomas Neumann wrote: +static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution. It seems that

Re: [PATCH] Avoid depending on destructor order

2022-09-25 Thread Iain Sandoe
> On 23 Sep 2022, at 15:30, David Edelsohn via Gcc-patches > wrote: > > On Fri, Sep 23, 2022 at 10:12 AM Thomas Neumann wrote: > >>> >>>+static const bool in_shutdown = false; >>> >>> I'll let Jason or others decide if this is the right solution. It seems >>> that in_shutdown also

Re: [PATCH] Avoid depending on destructor order

2022-09-23 Thread David Edelsohn via Gcc-patches
On Fri, Sep 23, 2022 at 10:12 AM Thomas Neumann wrote: > > > > +static const bool in_shutdown = false; > > > > I'll let Jason or others decide if this is the right solution. It seems > > that in_shutdown also could be declared outside the #ifdef and > > initialized as "false". > > sure,

Re: [PATCH] Avoid depending on destructor order

2022-09-23 Thread Thomas Neumann via Gcc-patches
+static const bool in_shutdown = false; I'll let Jason or others decide if this is the right solution.  It seems that in_shutdown also could be declared outside the #ifdef and initialized as "false". sure, either is fine. Moving it outside the #ifdef wastes one byte in the executable

Re: [PATCH] Avoid depending on destructor order

2022-09-23 Thread David Edelsohn via Gcc-patches
On Fri, Sep 23, 2022 at 9:38 AM Thomas Neumann wrote: > > This patch broke bootstrap on AIX and probably other targets. > > > > #ifdef ATOMIC_FDE_FAST_PATH > > #include "unwind-dw2-btree.h" > > > > static struct btree registered_frames; > > static bool in_shutdown; > > ... > > #else > > > >

Re: [PATCH] Avoid depending on destructor order

2022-09-23 Thread David Edelsohn via Gcc-patches
On Fri, Sep 23, 2022 at 9:38 AM Thomas Neumann wrote: > > This patch broke bootstrap on AIX and probably other targets. > > > > #ifdef ATOMIC_FDE_FAST_PATH > > #include "unwind-dw2-btree.h" > > > > static struct btree registered_frames; > > static bool in_shutdown; > > ... > > #else > > > >

Re: [PATCH] Avoid depending on destructor order

2022-09-23 Thread Thomas Neumann via Gcc-patches
This patch broke bootstrap on AIX and probably other targets. #ifdef ATOMIC_FDE_FAST_PATH #include "unwind-dw2-btree.h" static struct btree registered_frames; static bool in_shutdown; ... #else in_shutdown only is defined for ATOMIC_FDE_FAST_PATH but used in code / asserts not protected by

Re: [PATCH] Avoid depending on destructor order

2022-09-22 Thread Jason Merrill via Gcc-patches
On 9/19/22 12:20, Thomas Neumann wrote: In some scenarios (e.g., when mixing gcc and clang code), it can happen that frames are deregistered after the lookup structure has already been destroyed. That in itself would be fine, but it triggers an assert in __deregister_frame_info_bases that

[PATCH] Avoid depending on destructor order

2022-09-19 Thread Thomas Neumann via Gcc-patches
In some scenarios (e.g., when mixing gcc and clang code), it can happen that frames are deregistered after the lookup structure has already been destroyed. That in itself would be fine, but it triggers an assert in __deregister_frame_info_bases that expects to find the frame. To avoid that, we