All my gcc-11 compilers (Ubuntu 11.4.0-1ubuntu1~22.04) claim to support
the __retain__ attribute, but only riscv64-linux-gnu-gcc-11 and
x86_64-linux-gnu-gcc-11 (not x86_64-linux-gnux32-gcc-11!) actually do.
The arm-linux-gnueabi-gcc-11.5.0 compiler from kernel.org crosstool
fails in the same way:

    error: ‘retain’ attribute ignored [-Werror=attributes]

All my gcc-12 compilers seem to support the attribute.

Play it safe, and disable __retain unconditionally on gcc-11.

Fixes: 0a5d3258d7c97295 ("compiler_types.h: Define __retain for __attribute__((__retain__))")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Tony Ambardar <tony.ambardar@gmail.com>
---
Tested with the following gcc-11 compilers:

  1. All compilers available on Ubuntu 22.04LTS:

	aarch64-linux-gnu-gcc-11
	alpha-linux-gnu-gcc-11
	arm-linux-gnueabi-gcc-11
	arm-linux-gnueabihf-gcc-11
	hppa64-linux-gnu-gcc-11
	hppa-linux-gnu-gcc-11
	i686-linux-gnu-gcc-11
	m68k-linux-gnu-gcc-11
	powerpc64le-linux-gnu-gcc-11
	powerpc64-linux-gnu-gcc-11
	powerpc-linux-gnu-gcc-11
	riscv64-linux-gnu-gcc-11
	s390x-linux-gnu-gcc-11
	sh4-linux-gnu-gcc-11
	sparc64-linux-gnu-gcc-11
	x86_64-linux-gnu-gcc-11
	x86_64-linux-gnux32-gcc-11

  2. A few from kernel.org crosstool:

	ia64-linux-gcc-11.1.0
	sh2eb-linux-muslfdpic-gcc-11.2.0
	arm-linux-gnueabi-gcc-11.5.0

  3. A compiler from the J-Core folks:

	sh2eb-linux-muslfdpic-gcc-11.2.0

v2:
  - Update comment in <linux/compiler_types.h>,
  - Add Reviewed-by.
---
 include/linux/compiler-gcc.h   | 9 +++++++++
 include/linux/compiler_types.h | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index f805adaa316e9a21..bedeb76b63a34745 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -145,3 +145,12 @@
 #if GCC_VERSION < 90100
 #undef __alloc_size__
 #endif
+
+/*
+ * Most 11.x compilers claim to support it, but only riscv64-linux-gnu-gcc and
+ * x86_64-linux-gnu-gcc actually do.
+ */
+#if GCC_VERSION < 120000
+#undef __retain
+#define __retain
+#endif
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1a957ea2f4fe78ed..76ddf04a7e66f890 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -153,7 +153,7 @@ static inline void __chk_io_ptr(const volatile void __iomem *ptr) { }
  * being optimized out, but operates at the compiler/IR-level and may still
  * allow unintended removal of objects during linking.
  *
- * Optional: only supported since gcc >= 11, clang >= 13
+ * Optional: only supported since gcc >= 11 (partial), clang >= 13
  *
  *   gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-retain-function-attribute
  * clang: https://clang.llvm.org/docs/AttributeReference.html#retain
-- 
2.34.1

On Okt 02 2024, Geert Uytterhoeven wrote:

> + * Optional: only supported since gcc >= 11 (partial), clang >= 13

This is misleading.  gcc fully supports it since 11 as long as binutils
supports SHF_GNU_RETAIN.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Hi Andreas,

On Wed, Oct 2, 2024 at 7:00 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Okt 02 2024, Geert Uytterhoeven wrote:
>
> > + * Optional: only supported since gcc >= 11 (partial), clang >= 13
>
> This is misleading.  gcc fully supports it since 11 as long as binutils
> supports SHF_GNU_RETAIN.

It fails for me with arm-linux-gnueabihf-gcc-11 (gcc version 11.4.0
(Ubuntu 11.4.0-1ubuntu1~22.04)).

$ arm-linux-gnueabihf-as -v
GNU assembler version 2.38 (arm-linux-gnueabihf) using BFD version
(GNU Binutils for Ubuntu) 2.38

In response to v1, you replied:

| That ultimately depends on binutils support for SHF_GNU_RETAIN (2.36+).

So binutils 2.38-4ubuntu2.6 is sufficiently new, but it doesn't work?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Okt 03 2024, Geert Uytterhoeven wrote:

> | That ultimately depends on binutils support for SHF_GNU_RETAIN (2.36+).
>
> So binutils 2.38-4ubuntu2.6 is sufficiently new, but it doesn't work?

It ultimately depends on the binutils version the compiler was built
against.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Hi Andreas,

On Thu, Oct 3, 2024 at 10:42 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Okt 03 2024, Geert Uytterhoeven wrote:
> > | That ultimately depends on binutils support for SHF_GNU_RETAIN (2.36+).
> >
> > So binutils 2.38-4ubuntu2.6 is sufficiently new, but it doesn't work?
>
> It ultimately depends on the binutils version the compiler was built
> against.

Is there an easy way to check that version?

debian/rules for the gcc-11-cross-11ubuntu1.3 source package contains:

    VER_BINUTILS   := 2.37-5
    MIN_VER_BINUTILS   := 2.37-5

so in theory it could have been built again 2.37, which is still
sufficiently new.

"dpkg -s gcc-11-arm-linux-gnueabihf" says:

    Depends: [...] binutils-arm-linux-gnueabihf (>= 2.38) [...]

so I guess it was actually built against 2.38, which is OK.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Okt 03 2024, Geert Uytterhoeven wrote:

> Hi Andreas,
>
> On Thu, Oct 3, 2024 at 10:42 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Okt 03 2024, Geert Uytterhoeven wrote:
>> > | That ultimately depends on binutils support for SHF_GNU_RETAIN (2.36+).
>> >
>> > So binutils 2.38-4ubuntu2.6 is sufficiently new, but it doesn't work?
>>
>> It ultimately depends on the binutils version the compiler was built
>> against.
>
> Is there an easy way to check that version?

No.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

On Thu, Oct 3, 2024 at 11:02 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> No.

Is there a high enough minimum supported binutils per GCC major that
we could at least rely upon? Perhaps in the future? I guess nothing we
can really use, given https://gcc.gnu.org/install/prerequisites.html.

Otherwise, does it mean we need a build-time test?

Cheers,
Miguel

On Okt 03 2024, Miguel Ojeda wrote:

> Otherwise, does it mean we need a build-time test?

A simple gcc version test definitely does not suffice.

The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
is usually enabled by default (depends on glibc support, but that is
much older), but can be disabled with --disable-initfini-array.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> A simple gcc version test definitely does not suffice.

By build-time test, I meant compiling/running some small program to
check whether the compiler supports the feature or not.

Cheers,
Miguel

On Thu, Oct 3, 2024 at 2:28 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >
> > A simple gcc version test definitely does not suffice.
>
> By build-time test, I meant compiling/running some small program to
> check whether the compiler supports the feature or not.

Ah, sorry, I missed the "definitely" in your message. I think I
misunderstood your message.

Cheers,
Miguel

On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Okt 03 2024, Miguel Ojeda wrote:
>
> > Otherwise, does it mean we need a build-time test?
>
> A simple gcc version test definitely does not suffice.
>
> The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
> is usually enabled by default (depends on glibc support, but that is
> much older), but can be disabled with --disable-initfini-array.

FTR, no --disable-initfini-array seen here:

$ arm-linux-gnueabihf-gcc-11 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/arm-linux-gnueabihf-gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/11/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --without-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a+fp
--with-float=hard --with-mode=thumb --disable-werror
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabihf
--program-prefix=arm-linux-gnueabihf-
--includedir=/usr/arm-linux-gnueabihf/include
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Okt 03 2024, Geert Uytterhoeven wrote:

> On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Okt 03 2024, Miguel Ojeda wrote:
>>
>> > Otherwise, does it mean we need a build-time test?
>>
>> A simple gcc version test definitely does not suffice.
>>
>> The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
>> is usually enabled by default (depends on glibc support, but that is
>> much older), but can be disabled with --disable-initfini-array.
>
> FTR, no --disable-initfini-array seen here:

--disable-initfini-array is the default for cross compilers.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Hi Andreas,

On Thu, Oct 3, 2024 at 2:34 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Okt 03 2024, Geert Uytterhoeven wrote:
> > On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> On Okt 03 2024, Miguel Ojeda wrote:
> >> > Otherwise, does it mean we need a build-time test?
> >>
> >> A simple gcc version test definitely does not suffice.
> >>
> >> The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
> >> is usually enabled by default (depends on glibc support, but that is
> >> much older), but can be disabled with --disable-initfini-array.
> >
> > FTR, no --disable-initfini-array seen here:
>
> --disable-initfini-array is the default for cross compilers.

Apparently not for cross compilers targeting riscv64?
I.e. no --enable-initfini-array seen here:

$ riscv64-linux-gnu-gcc-11 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/riscv64-linux-gnu-gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/riscv64-linux-gnu/11/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --without-target-system-zlib
--enable-multiarch --disable-werror --disable-multilib
--with-arch=rv64gc --with-abi=lp64d --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=riscv64-linux-gnu --program-prefix=riscv64-linux-gnu-
--includedir=/usr/riscv64-linux-gnu/include
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Okt 03 2024, Geert Uytterhoeven wrote:

> Hi Andreas,
>
> On Thu, Oct 3, 2024 at 2:34 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Okt 03 2024, Geert Uytterhoeven wrote:
>> > On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> >> On Okt 03 2024, Miguel Ojeda wrote:
>> >> > Otherwise, does it mean we need a build-time test?
>> >>
>> >> A simple gcc version test definitely does not suffice.
>> >>
>> >> The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
>> >> is usually enabled by default (depends on glibc support, but that is
>> >> much older), but can be disabled with --disable-initfini-array.
>> >
>> > FTR, no --disable-initfini-array seen here:
>>
>> --disable-initfini-array is the default for cross compilers.
>
> Apparently not for cross compilers targeting riscv64?

Yes, targets in the aarch64 era or newer enable initfini_array by
default.  Also, gcc 12+ generally defaults to --enable-initfini-array on
Linux as well.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

On Thu, Oct 3, 2024 at 2:57 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Okt 03 2024, Geert Uytterhoeven wrote:
> > On Thu, Oct 3, 2024 at 2:34 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> On Okt 03 2024, Geert Uytterhoeven wrote:
> >> > On Thu, Oct 3, 2024 at 2:11 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >> >> On Okt 03 2024, Miguel Ojeda wrote:
> >> >> > Otherwise, does it mean we need a build-time test?
> >> >>
> >> >> A simple gcc version test definitely does not suffice.
> >> >>
> >> >> The suport for retain also depends on HAVE_INITFINI_ARRAY_SUPPORT, which
> >> >> is usually enabled by default (depends on glibc support, but that is
> >> >> much older), but can be disabled with --disable-initfini-array.
> >> >
> >> > FTR, no --disable-initfini-array seen here:
> >>
> >> --disable-initfini-array is the default for cross compilers.
> >
> > Apparently not for cross compilers targeting riscv64?
>
> Yes, targets in the aarch64 era or newer enable initfini_array by
> default.  Also, gcc 12+ generally defaults to --enable-initfini-array on
> Linux as well.

As I have upgraded to Ubuntu 24.04.1 LTS, my main cross-compilers are
now based on gcc-13, which does not exhibit the issue (it can still be
reproduced by building with CC=arm-linux-gnueabi-gcc-11). Hence I have
no longer an immediate need for this patch, and will stop continuing
this non-conclusive discussion. The distro people can pick up my patch
when they get to gcc-11 ;-)

Happy 2025!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Wed, Oct 2, 2024 at 9:25 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> - * Optional: only supported since gcc >= 11, clang >= 13
> + * Optional: only supported since gcc >= 11 (partial), clang >= 13

Hmm... "partial" does not give much information -- perhaps something like:

    * Optional: only supported since gcc >= 11 (partial, see
compiler-gcc.h), gcc >= 12, clang >= 13

What do you think?

With something like that:

Acked-by: Miguel Ojeda <ojeda@kernel.org>

Cheers,
Miguel