public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] [gdb/build] Workaround gcc PR113599
@ 2024-01-25 14:21 Tom de Vries
  2024-01-25 14:51 ` Tom Tromey
  2024-01-25 15:27 ` Sam James
  0 siblings, 2 replies; 4+ messages in thread
From: Tom de Vries @ 2024-01-25 14:21 UTC (permalink / raw)
  To: gdb-patches

Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
[PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
reported in PR build/31281.

Work around this by flipping inherit order:
...
-class thread_info : public refcounted_object,
-		    public intrusive_list_node<thread_info>
+class thread_info : public intrusive_list_node<thread_info>,
+		    public refcounted_object
...

An argument could be made that this isn't necessary, because this occurred in
an unreleased gcc version.

However, I think it could be useful when bisecting gcc for other problems in
building gdb.  Having this workaround means the bisect won't reintroduce the
problem.  Furthermore, the workaround is harmless.

Tested on Fedora rawhide x86_64.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
---
 gdb/gdbthread.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h
index e7035d40ad4..1d9730fd1fa 100644
--- a/gdb/gdbthread.h
+++ b/gdb/gdbthread.h
@@ -244,10 +244,11 @@ using private_thread_info_up = std::unique_ptr<private_thread_info>;
    strong reference, and is thus not accounted for in the thread's
    refcount.
 
-   The intrusive_list_node base links threads in a per-inferior list.  */
+   The intrusive_list_node base links threads in a per-inferior list.
+   We place it first in the inherit orer to work around PR gcc/113599.  */
 
-class thread_info : public refcounted_object,
-		    public intrusive_list_node<thread_info>
+class thread_info : public intrusive_list_node<thread_info>,
+		    public refcounted_object
 {
 public:
   explicit thread_info (inferior *inf, ptid_t ptid);

base-commit: 726f209eb1b05842d816eac8b0b8f9c7f6cd9fbc
-- 
2.35.3


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] [gdb/build] Workaround gcc PR113599
  2024-01-25 14:21 [PATCH] [gdb/build] Workaround gcc PR113599 Tom de Vries
@ 2024-01-25 14:51 ` Tom Tromey
  2024-01-25 15:27 ` Sam James
  1 sibling, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2024-01-25 14:51 UTC (permalink / raw)
  To: Tom de Vries; +Cc: gdb-patches

>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

Tom> However, I think it could be useful when bisecting gcc for other problems in
Tom> building gdb.  Having this workaround means the bisect won't reintroduce the
Tom> problem.  Furthermore, the workaround is harmless.

I think the change is harmless and well-documented, so I think it is ok.
Approved-By: Tom Tromey <tom@tromey.com>

thanks,
Tom

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] [gdb/build] Workaround gcc PR113599
  2024-01-25 14:21 [PATCH] [gdb/build] Workaround gcc PR113599 Tom de Vries
  2024-01-25 14:51 ` Tom Tromey
@ 2024-01-25 15:27 ` Sam James
  2024-01-25 15:30   ` Tom de Vries
  1 sibling, 1 reply; 4+ messages in thread
From: Sam James @ 2024-01-25 15:27 UTC (permalink / raw)
  To: Tom de Vries; +Cc: gdb-patches


Tom de Vries <tdevries@suse.de> writes:

> Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
> [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
> reported in PR build/31281.
>
> Work around this by flipping inherit order:
> ...
> -class thread_info : public refcounted_object,
> -		    public intrusive_list_node<thread_info>
> +class thread_info : public intrusive_list_node<thread_info>,
> +		    public refcounted_object
> ...
>
> An argument could be made that this isn't necessary, because this occurred in
> an unreleased gcc version.
>
> However, I think it could be useful when bisecting gcc for other problems in
> building gdb.  Having this workaround means the bisect won't reintroduce the
> problem.  Furthermore, the workaround is harmless.
>
> Tested on Fedora rawhide x86_64.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
> ---
>  gdb/gdbthread.h | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h
> index e7035d40ad4..1d9730fd1fa 100644
> --- a/gdb/gdbthread.h
> +++ b/gdb/gdbthread.h
> @@ -244,10 +244,11 @@ using private_thread_info_up = std::unique_ptr<private_thread_info>;
>     strong reference, and is thus not accounted for in the thread's
>     refcount.
>  
> -   The intrusive_list_node base links threads in a per-inferior list.  */
> +   The intrusive_list_node base links threads in a per-inferior list.
> +   We place it first in the inherit orer to work around PR gcc/113599.  */

order

>  
> -class thread_info : public refcounted_object,
> -		    public intrusive_list_node<thread_info>
> +class thread_info : public intrusive_list_node<thread_info>,
> +		    public refcounted_object
>  {
>  public:
>    explicit thread_info (inferior *inf, ptid_t ptid);
>
> base-commit: 726f209eb1b05842d816eac8b0b8f9c7f6cd9fbc


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] [gdb/build] Workaround gcc PR113599
  2024-01-25 15:27 ` Sam James
@ 2024-01-25 15:30   ` Tom de Vries
  0 siblings, 0 replies; 4+ messages in thread
From: Tom de Vries @ 2024-01-25 15:30 UTC (permalink / raw)
  To: Sam James; +Cc: gdb-patches

On 1/25/24 16:27, Sam James wrote:
> 
> Tom de Vries <tdevries@suse.de> writes:
> 
>> Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
>> [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
>> reported in PR build/31281.
>>
>> Work around this by flipping inherit order:
>> ...
>> -class thread_info : public refcounted_object,
>> -		    public intrusive_list_node<thread_info>
>> +class thread_info : public intrusive_list_node<thread_info>,
>> +		    public refcounted_object
>> ...
>>
>> An argument could be made that this isn't necessary, because this occurred in
>> an unreleased gcc version.
>>
>> However, I think it could be useful when bisecting gcc for other problems in
>> building gdb.  Having this workaround means the bisect won't reintroduce the
>> problem.  Furthermore, the workaround is harmless.
>>
>> Tested on Fedora rawhide x86_64.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
>> ---
>>   gdb/gdbthread.h | 7 ++++---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h
>> index e7035d40ad4..1d9730fd1fa 100644
>> --- a/gdb/gdbthread.h
>> +++ b/gdb/gdbthread.h
>> @@ -244,10 +244,11 @@ using private_thread_info_up = std::unique_ptr<private_thread_info>;
>>      strong reference, and is thus not accounted for in the thread's
>>      refcount.
>>   
>> -   The intrusive_list_node base links threads in a per-inferior list.  */
>> +   The intrusive_list_node base links threads in a per-inferior list.
>> +   We place it first in the inherit orer to work around PR gcc/113599.  */
> 
> order
> 

Thanks for catching that, fixed.

- Tom

>>   
>> -class thread_info : public refcounted_object,
>> -		    public intrusive_list_node<thread_info>
>> +class thread_info : public intrusive_list_node<thread_info>,
>> +		    public refcounted_object
>>   {
>>   public:
>>     explicit thread_info (inferior *inf, ptid_t ptid);
>>
>> base-commit: 726f209eb1b05842d816eac8b0b8f9c7f6cd9fbc
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-01-25 15:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-25 14:21 [PATCH] [gdb/build] Workaround gcc PR113599 Tom de Vries
2024-01-25 14:51 ` Tom Tromey
2024-01-25 15:27 ` Sam James
2024-01-25 15:30   ` Tom de Vries

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).