[PATCH] [gdb/build] Work around GCC ipa-modref bug

[PATCH] [gdb/build] Work around GCC ipa-modref bug

[Tom de Vries]

PR mi/32571 reports the following problem:
...
$ gdb -q -batch -ex "b bla.c:100"
<random output>
Make breakpoint pending on future shared library load? (y or [n]) \
  [answered N; input not from terminal]
...
while this is expected:
...
$ gdb -q -batch -ex "b bla.c:100"
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) \
  [answered N; input not from terminal]
...

A few factors in reproducing this are building gdb using gcc 14,
"-O2 -flto=auto" and --disable-nls.  For more details, see the PR.

This turns out to be caused by a GCC PR [1], more specifically a problem in
ipa-modref.

Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
assuming the GCC 16.1 release will contain a fix.

Tested on aarch64-linux and x86_64-linux.

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

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
---
 gdbsupport/common-defs.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
index 07caf3bd7e4..bdf04d9ec09 100644
--- a/gdbsupport/common-defs.h
+++ b/gdbsupport/common-defs.h
@@ -27,6 +27,14 @@
 #pragma GCC optimize("-fno-hoist-adjacent-loads")
 #endif
 
+#if defined (__GNUC__) && !defined (__clang__) \
+  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
+      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
+/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
+   the gcc 16.1 release.  */
+#pragma GCC optimize("-fno-ipa-modref")
+#endif
+
 #include <gdbsupport/config.h>
 
 #undef PACKAGE_NAME

base-commit: 6ab3f09a682adcb4e841faf7fc19dea2671debed
-- 
2.43.0

Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Sam James]

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

> PR mi/32571 reports the following problem:
> ...
> $ gdb -q -batch -ex "b bla.c:100"
> <random output>
> Make breakpoint pending on future shared library load? (y or [n]) \
>   [answered N; input not from terminal]
> ...
> while this is expected:
> ...
> $ gdb -q -batch -ex "b bla.c:100"
> No symbol table is loaded.  Use the "file" command.
> Make breakpoint pending on future shared library load? (y or [n]) \
>   [answered N; input not from terminal]
> ...
>
> A few factors in reproducing this are building gdb using gcc 14,
> "-O2 -flto=auto" and --disable-nls.  For more details, see the PR.
>
> This turns out to be caused by a GCC PR [1], more specifically a problem in
> ipa-modref.
>
> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
> assuming the GCC 16.1 release will contain a fix.
>
> Tested on aarch64-linux and x86_64-linux.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
> ---
>  gdbsupport/common-defs.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
> index 07caf3bd7e4..bdf04d9ec09 100644
> --- a/gdbsupport/common-defs.h
> +++ b/gdbsupport/common-defs.h
> @@ -27,6 +27,14 @@
>  #pragma GCC optimize("-fno-hoist-adjacent-loads")
>  #endif
>  
> +#if defined (__GNUC__) && !defined (__clang__) \
> +  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
> +      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
> +/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
> +   the gcc 16.1 release.  */
> +#pragma GCC optimize("-fno-ipa-modref")
> +#endif
> +
>  #include <gdbsupport/config.h>
>  
>  #undef PACKAGE_NAME
>
> base-commit: 6ab3f09a682adcb4e841faf7fc19dea2671debed

LGTM. Thanks for reducing it and digging into this.

Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Andrew Burgess]

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

> PR mi/32571 reports the following problem:
> ...
> $ gdb -q -batch -ex "b bla.c:100"
> <random output>
> Make breakpoint pending on future shared library load? (y or [n]) \
>   [answered N; input not from terminal]
> ...
> while this is expected:
> ...
> $ gdb -q -batch -ex "b bla.c:100"
> No symbol table is loaded.  Use the "file" command.
> Make breakpoint pending on future shared library load? (y or [n]) \
>   [answered N; input not from terminal]
> ...
>
> A few factors in reproducing this are building gdb using gcc 14,
> "-O2 -flto=auto" and --disable-nls.  For more details, see the PR.
>
> This turns out to be caused by a GCC PR [1], more specifically a problem in
> ipa-modref.
>
> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
> assuming the GCC 16.1 release will contain a fix.

First, massive thanks for tracking this issue down.

>
> Tested on aarch64-linux and x86_64-linux.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
> ---
>  gdbsupport/common-defs.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
> index 07caf3bd7e4..bdf04d9ec09 100644
> --- a/gdbsupport/common-defs.h
> +++ b/gdbsupport/common-defs.h
> @@ -27,6 +27,14 @@
>  #pragma GCC optimize("-fno-hoist-adjacent-loads")
>  #endif
>  
> +#if defined (__GNUC__) && !defined (__clang__) \
> +  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
> +      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
> +/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
> +   the gcc 16.1 release.  */

Should that not be gcc/120987?  Also I notice the target milestone on
that gcc bug is set to 13.5, maybe that field is used differently for
gcc, but I was expecting to see 16.1 maybe?  I know there's limits on
what we can do to ensure gcc fix this, but might as well get these
fields as correct as possible :)

With the comment updated:

Approved-By: Andrew Burgess <aburgess@redhat.com>

Thanks,
Andrew


> +#pragma GCC optimize("-fno-ipa-modref")
> +#endif
> +
>  #include <gdbsupport/config.h>
>  
>  #undef PACKAGE_NAME
>
> base-commit: 6ab3f09a682adcb4e841faf7fc19dea2671debed
> -- 
> 2.43.0

Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Sam James]

Andrew Burgess <aburgess@redhat.com> writes:

> Tom de Vries <tdevries@suse.de> writes:
>
>> PR mi/32571 reports the following problem:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> <random output>
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>   [answered N; input not from terminal]
>> ...
>> while this is expected:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> No symbol table is loaded.  Use the "file" command.
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>   [answered N; input not from terminal]
>> ...
>>
>> A few factors in reproducing this are building gdb using gcc 14,
>> "-O2 -flto=auto" and --disable-nls.  For more details, see the PR.
>>
>> This turns out to be caused by a GCC PR [1], more specifically a problem in
>> ipa-modref.
>>
>> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
>> assuming the GCC 16.1 release will contain a fix.
>
> First, massive thanks for tracking this issue down.
>
>>
>> Tested on aarch64-linux and x86_64-linux.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
>> ---
>>  gdbsupport/common-defs.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
>> index 07caf3bd7e4..bdf04d9ec09 100644
>> --- a/gdbsupport/common-defs.h
>> +++ b/gdbsupport/common-defs.h
>> @@ -27,6 +27,14 @@
>>  #pragma GCC optimize("-fno-hoist-adjacent-loads")
>>  #endif
>>  
>> +#if defined (__GNUC__) && !defined (__clang__) \
>> +  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
>> +      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
>> +/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
>> +   the gcc 16.1 release.  */
>
> Should that not be gcc/120987?

Ah, yeah.

> Also I notice the target milestone on
> that gcc bug is set to 13.5, maybe that field is used differently for
> gcc, but I was expecting to see 16.1 maybe?  I know there's limits on
> what we can do to ensure gcc fix this, but might as well get these
> fields as correct as possible :)

It's correct as it is in terms of the upstream bug milestone. The milestone is the
first supported version it affects. gdb doesn't have that issue as it
tends to not support multiple branches and doesn't always do point
releases for the branches.

> [...]

sam

Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Tom de Vries]

On 7/12/25 21:43, Andrew Burgess wrote:
> Tom de Vries <tdevries@suse.de> writes:
> 
>> PR mi/32571 reports the following problem:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> <random output>
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>    [answered N; input not from terminal]
>> ...
>> while this is expected:
>> ...
>> $ gdb -q -batch -ex "b bla.c:100"
>> No symbol table is loaded.  Use the "file" command.
>> Make breakpoint pending on future shared library load? (y or [n]) \
>>    [answered N; input not from terminal]
>> ...
>>
>> A few factors in reproducing this are building gdb using gcc 14,
>> "-O2 -flto=auto" and --disable-nls.  For more details, see the PR.
>>
>> This turns out to be caused by a GCC PR [1], more specifically a problem in
>> ipa-modref.
>>
>> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
>> assuming the GCC 16.1 release will contain a fix.
> 

Hi Andrew,

thanks for the review.

> First, massive thanks for tracking this issue down.

Likewise, thank you and every else who worked on tracking this down.

In particular, I found your comment describing how you reproduced it in 
arch linux helpful, and it triggered me to try the same (but without 
using the package infrastructure), which was the first time I managed to 
reproduce it.

>> Tested on aarch64-linux and x86_64-linux.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32571
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
>> ---
>>   gdbsupport/common-defs.h | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
>> index 07caf3bd7e4..bdf04d9ec09 100644
>> --- a/gdbsupport/common-defs.h
>> +++ b/gdbsupport/common-defs.h
>> @@ -27,6 +27,14 @@
>>   #pragma GCC optimize("-fno-hoist-adjacent-loads")
>>   #endif
>>   
>> +#if defined (__GNUC__) && !defined (__clang__) \
>> +  && ((__GNUC__ >= 12 && __GNUC__ <= 15)       \
>> +      || (__GNUC__ == 16 && __GNUC_MINOR__ < 1))
>> +/* Work around PR gcc/110799 starting gcc 12, and assume it will be fixed in
>> +   the gcc 16.1 release.  */
> 
> Should that not be gcc/120987?

Thanks for noticing this.  Fixed before pushing.

> Also I notice the target milestone on
> that gcc bug is set to 13.5, maybe that field is used differently for
> gcc, but I was expecting to see 16.1 maybe?  I know there's limits on
> what we can do to ensure gcc fix this, but might as well get these
> fields as correct as possible :)
> 
> With the comment updated:
> 
> Approved-By: Andrew Burgess <aburgess@redhat.com>
> 

I've pushed this.

After doing so, Richard Biener commented in the GCC PR ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987#c25 ):
...
It's usually better to place a noipa attribute on a select function
where the issue shows up than disabling a whole pass which might
lead to other latent bugs pop up here and there given test coverage
with -fno-ipa-* or -fno-tree-* is very weak.
...

But FWIW, I prefer disabling the pass on the basis that I don't want to 
run into the same problem again in a different form and place.

Thanks,
- Tom

> Thanks,
> Andrew
> 
> 
>> +#pragma GCC optimize("-fno-ipa-modref")
>> +#endif
>> +
>>   #include <gdbsupport/config.h>
>>   
>>   #undef PACKAGE_NAME
>>
>> base-commit: 6ab3f09a682adcb4e841faf7fc19dea2671debed
>> -- 
>> 2.43.0
> 

Re: [PATCH] [gdb/build] Work around GCC ipa-modref bug

[Tom de Vries]

On 7/12/25 3:16 PM, Tom de Vries wrote:
> Work around this by disabling ipa-modref for GCC versions 12-15 and 16.0,
> assuming the GCC 16.1 release will contain a fix.
To follow up on this, a patch got recently committed to fix the PR ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987 ), which AFAIU means 
it will be fixed in GCC 16.1.

So, the assumption turned out to be correct, and there's no need to 
patch the workaround to extend it to more GCC versions.

Thanks,
- Tom