[RFC] s390: Deprecate -m31 support

Message ID 20260109170347.1918445-1-stefansf@linux.ibm.com
State New
Headers
Series [RFC] s390: Deprecate -m31 support |

Commit Message

Stefan Schulze Frielinghaus Jan. 9, 2026, 5:03 p.m. UTC
  From: Stefan Schulze Frielinghaus <stefansf@gcc.gnu.org>

Since stage 4 draws ever closer I'm posting this already.  However,
I'm not pushing this since it would break bootstrap.  PR 122794 is
basically fixed, I'm just awaiting green light.  However, in the
meantime another build problem showed up.  This time while building
libstdc++:

cc1plus: warning: '-m31' is deprecated and support will be removed; use '-m64' instead [-Wdeprecated]
/gcc/src/libstdc++-v3/src/c++98/compatibility.cc:392:4: error: 'void {anonymous}::_Y_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl(...)' aliased to undefined symbol '_ZNSt13basic_istreamIwSt11char_traitsIwEE8ignoreXXEl'
  392 |    _Y##name(...) \
      |    ^~
/gcc/src/libstdc++-v3/src/c++98/compatibility.cc:403:31: note: in expansion of macro '_GLIBCXX_3_4_5_SYMVER'
  403 | #define _GLIBCXX_APPLY_SYMVER _GLIBCXX_3_4_5_SYMVER
      |                               ^~~~~~~~~~~~~~~~~~~~~
...

Without this patch, the build succeeds.

Anyhow, in order to give users a chance to disable the warning, I went
for -Wno-deprecated.

Starting with Linux 6.19, compat syscalls will be removed.  Furthermore,
the next glibc release deprecates -m31 support.  Therefore, the current
plan for GCC is to also deprecate -m31 and emit a warning for GCC 16 and
remove -m31 entirely for GCC 17.

Any objections to this approach?

-- >8 --

Support for -m31 is deprecated and support will be removed.
---
 gcc/config/s390/s390.cc | 4 ++++
 1 file changed, 4 insertions(+)
  

Comments

Richard Biener Jan. 9, 2026, 7:02 p.m. UTC | #1
> Am 09.01.2026 um 18:05 schrieb Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>:
> 
> From: Stefan Schulze Frielinghaus <stefansf@gcc.gnu.org>
> 
> Since stage 4 draws ever closer I'm posting this already.  However,
> I'm not pushing this since it would break bootstrap.  PR 122794 is
> basically fixed, I'm just awaiting green light.  However, in the
> meantime another build problem showed up.  This time while building
> libstdc++:
> 
> cc1plus: warning: '-m31' is deprecated and support will be removed; use '-m64' instead [-Wdeprecated]
> /gcc/src/libstdc++-v3/src/c++98/compatibility.cc:392:4: error: 'void {anonymous}::_Y_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl(...)' aliased to undefined symbol '_ZNSt13basic_istreamIwSt11char_traitsIwEE8ignoreXXEl'
>  392 |    _Y##name(...) \
>      |    ^~
> /gcc/src/libstdc++-v3/src/c++98/compatibility.cc:403:31: note: in expansion of macro '_GLIBCXX_3_4_5_SYMVER'
>  403 | #define _GLIBCXX_APPLY_SYMVER _GLIBCXX_3_4_5_SYMVER
>      |                               ^~~~~~~~~~~~~~~~~~~~~
> ...
> 
> Without this patch, the build succeeds.
> 
> Anyhow, in order to give users a chance to disable the warning, I went
> for -Wno-deprecated.
> 
> Starting with Linux 6.19, compat syscalls will be removed.  Furthermore,
> the next glibc release deprecates -m31 support.  Therefore, the current
> plan for GCC is to also deprecate -m31 and emit a warning for GCC 16 and
> remove -m31 entirely for GCC 17.
> 
> Any objections to this approach?

Maybe diagnose at configure time when not —disable-multilib?  Or drop -m31 from the default multilb set now, requiring explicit enablement?  I find diagnostic at each invocation quite intrusive.

Richard 

> 
> -- >8 --
> 
> Support for -m31 is deprecated and support will be removed.
> ---
> gcc/config/s390/s390.cc | 4 ++++
> 1 file changed, 4 insertions(+)
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 28a025be4e8..eba5a4ee6b6 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -16711,6 +16711,10 @@ s390_option_override_internal (struct gcc_options *opts,
>     }
> #endif
> 
> +  if (!TARGET_64BIT)
> +    warning (OPT_Wdeprecated,
> +    "%<-m31%> is deprecated and support will be removed; use %<-m64%> instead");
> +
> #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
>   if (!TARGET_LONG_DOUBLE_128_P (opts_set->x_target_flags))
>     opts->x_target_flags |= MASK_LONG_DOUBLE_128;
> --
> 2.49.0
>
  
Stefan Schulze Frielinghaus Jan. 9, 2026, 8:13 p.m. UTC | #2
On Fri, Jan 09, 2026 at 08:02:01PM +0100, Richard Biener wrote:
> 
> 
> > Am 09.01.2026 um 18:05 schrieb Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>:
> > 
> > From: Stefan Schulze Frielinghaus <stefansf@gcc.gnu.org>
> > 
> > Since stage 4 draws ever closer I'm posting this already.  However,
> > I'm not pushing this since it would break bootstrap.  PR 122794 is
> > basically fixed, I'm just awaiting green light.  However, in the
> > meantime another build problem showed up.  This time while building
> > libstdc++:
> > 
> > cc1plus: warning: '-m31' is deprecated and support will be removed; use '-m64' instead [-Wdeprecated]
> > /gcc/src/libstdc++-v3/src/c++98/compatibility.cc:392:4: error: 'void {anonymous}::_Y_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl(...)' aliased to undefined symbol '_ZNSt13basic_istreamIwSt11char_traitsIwEE8ignoreXXEl'
> >  392 |    _Y##name(...) \
> >      |    ^~
> > /gcc/src/libstdc++-v3/src/c++98/compatibility.cc:403:31: note: in expansion of macro '_GLIBCXX_3_4_5_SYMVER'
> >  403 | #define _GLIBCXX_APPLY_SYMVER _GLIBCXX_3_4_5_SYMVER
> >      |                               ^~~~~~~~~~~~~~~~~~~~~
> > ...
> > 
> > Without this patch, the build succeeds.
> > 
> > Anyhow, in order to give users a chance to disable the warning, I went
> > for -Wno-deprecated.
> > 
> > Starting with Linux 6.19, compat syscalls will be removed.  Furthermore,
> > the next glibc release deprecates -m31 support.  Therefore, the current
> > plan for GCC is to also deprecate -m31 and emit a warning for GCC 16 and
> > remove -m31 entirely for GCC 17.
> > 
> > Any objections to this approach?
> 
> Maybe diagnose at configure time when not —disable-multilib?  Or drop -m31 from the default multilb set now, requiring explicit enablement?  I find diagnostic at each invocation quite intrusive.

I agree.  That's why I wanted to make it suppressible via
-Wno-deprecated, however, strictly speaking this also disables other
warnings which might not be desirable, and I certainly do not want to go
overboard by introducing some extra option just for suppressing a
single deprecation warning.

I also thought about a configure diagnostics but decided against it
because users won't see it unless they build gcc on their own with
multilib enabled.  Giving this a second thought, users have to build gcc
with multilib support anyway since most distributions do not ship gcc
with multilib support for s390.  I will give this another round
internally.

Thanks for your thoughts!  Much appreciated.

Cheers,
Stefan

> 
> Richard 
> 
> > 
> > -- >8 --
> > 
> > Support for -m31 is deprecated and support will be removed.
> > ---
> > gcc/config/s390/s390.cc | 4 ++++
> > 1 file changed, 4 insertions(+)
> > 
> > diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> > index 28a025be4e8..eba5a4ee6b6 100644
> > --- a/gcc/config/s390/s390.cc
> > +++ b/gcc/config/s390/s390.cc
> > @@ -16711,6 +16711,10 @@ s390_option_override_internal (struct gcc_options *opts,
> >     }
> > #endif
> > 
> > +  if (!TARGET_64BIT)
> > +    warning (OPT_Wdeprecated,
> > +    "%<-m31%> is deprecated and support will be removed; use %<-m64%> instead");
> > +
> > #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
> >   if (!TARGET_LONG_DOUBLE_128_P (opts_set->x_target_flags))
> >     opts->x_target_flags |= MASK_LONG_DOUBLE_128;
> > --
> > 2.49.0
> >
  

Patch

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 28a025be4e8..eba5a4ee6b6 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -16711,6 +16711,10 @@  s390_option_override_internal (struct gcc_options *opts,
     }
 #endif
 
+  if (!TARGET_64BIT)
+    warning (OPT_Wdeprecated,
+	"%<-m31%> is deprecated and support will be removed; use %<-m64%> instead");
+
 #ifdef TARGET_DEFAULT_LONG_DOUBLE_128
   if (!TARGET_LONG_DOUBLE_128_P (opts_set->x_target_flags))
     opts->x_target_flags |= MASK_LONG_DOUBLE_128;