> -----Original Message-----
> From: Kyrylo Tkachov <[email protected]>
> Sent: Friday, January 17, 2025 1:22 PM
> To: Tamar Christina <[email protected]>
> Cc: GCC Patches <[email protected]>; nd <[email protected]>; Richard
> Earnshaw <[email protected]>; [email protected]; Richard
> Sandiford <[email protected]>
> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after
> deprecation
>
>
>
> > On 17 Jan 2025, at 14:06, Tamar Christina <[email protected]> wrote:
> >
> >> -----Original Message-----
> >> From: Kyrylo Tkachov <[email protected]>
> >> Sent: Friday, January 17, 2025 1:04 PM
> >> To: Tamar Christina <[email protected]>
> >> Cc: GCC Patches <[email protected]>; nd <[email protected]>; Richard
> >> Earnshaw <[email protected]>; [email protected]; Richard
> >> Sandiford <[email protected]>
> >> Subject: Re: [PATCH]AArch64: Drop ILP32 from default elf multilibs after
> >> deprecation
> >>
> >>
> >>
> >>> On 17 Jan 2025, at 13:56, Tamar Christina <[email protected]> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> Following the deprecation of ILP32 *-elf builds fail now due to -Werror
> >>> on the
> >>> deprecation warning. This is because on embedded builds ILP32 is part of
> >>> the
> >>> default multilib.
> >>>
> >>> This patch removed it from the default target as the build would fail
> >>> anyway.
> >>>
> >>> Cross compiled on aarch64-none-elf and build succeeds now.
> >>>
> >>> Ok for master?
> >>
> >> I was going to say that it’s more common to just announce deprecation in
> >> the
> >> documentation/release notes for one release cycle, to give time for
> >> potential
> users
> >> to come forward.
> >> If we remove the multilib build now we’d be helping the support bitrot much
> >> faster, which would make it harder to restore if such a user does come
> >> forward.
> >>
> >
> > The alternative approach would be to suppress the warning during build, the
> downside
> > is ofcourse that this warning does not have a unique identifier, so I
> > believe we'd
> have to
> > suppress all deprecation warnings:
> >
> > cc1: error: '-mabi=ilp32' is deprecated [-Werror=deprecated]
> >
> > But could work..
> >
>
> I think if the warning suppression only happened for the ILP32 multilib build
> that
> would be okay.
> Other deprecation warnings would be caught in the LP64 build
I can make that work by conditionally changing MULTILIB_OPTIONS in
gcc/config/aarch64/t-aarch64 when it's collecting the options for ILP32.
What do others think?
Thanks,
Tamar
>
> Kyrill
>
> > Cheers,
> > Tamar
> >
> >> But it also seems odd to build an entire multilib for a deprecated feature
> >> so I’m
> not
> >> opposed to it.
> >> I don’t know if we document the ILP32 multilib somewhere. If so, it should
> >> be
> >> updated.
> >> In any case the gcc-15 release notes should also mention this change.
> >>
> >> Thanks,
> >> Kyrill
> >>
> >>>
> >>> Sending this out in case there are no objections to the approach
> >>>
> >>> Thanks,
> >>> Tamar
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> * config.gcc (aarch64-*-elf): Drop ILP32 from default multilibs.
> >>>
> >>> ---
> >>> diff --git a/gcc/config.gcc b/gcc/config.gcc
> >>> index
> >>
> 55e37146ee0356b67b8a1a09d263eccdf69cd91a..432798d16fdbce099f69821c
> >> 3a0ad91905286777 100644
> >>> --- a/gcc/config.gcc
> >>> +++ b/gcc/config.gcc
> >>> @@ -1210,7 +1210,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-
> *-
> >> rtems*)
> >>> esac
> >>> aarch64_multilibs="${with_multilib_list}"
> >>> if test "$aarch64_multilibs" = "default"; then
> >>> - aarch64_multilibs="lp64,ilp32"
> >>> + aarch64_multilibs="lp64"
> >>> fi
> >>> aarch64_multilibs=`echo $aarch64_multilibs | sed -e 's/,/ /g'`
> >>> for aarch64_multilib in ${aarch64_multilibs}; do
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> <rb19161.patch>
> >
