On Fri, 14 Feb 2025 21:03:46 +0800, Jin Ma wrote: > Create a new hook to let target could override the multi-lib-os result. > > The motivation for this change arises from the fact that using > TARGET_COMPUTE_MULTILIB to override the original multilib_dir can lead > to unexpected behavior with multilib_os_dir. > > In our build scripts, we establish a connection between multilib_os_dir > and multilib_dir. For example, in gcc/config/riscv/t-linux, we set > multilib_os_dir to be the parent directory of multilib_dir. However, > when TARGET_COMPUTE_MULTILIB overrides multilib_dir and returns a reused > result for multilib_dir, multilib_os_dir ends up being identical to > multilib_dir. This discrepancy is clearly inconsistent with our > expectations. > > gcc/ChangeLog: > > * common/common-target.def (compute_multilib_os): New. > * common/common-targhooks.cc (default_compute_multilib_os): New. > * common/common-targhooks.h (default_compute_multilib_os): New. > * doc/tm.texi (TARGET_COMPUTE_MULTILIB_OS): New. > * doc/tm.texi.in: Regen. > * gcc.cc (set_multilib_dir): Call targetm_common.compute_multilib_os. > --- > gcc/common/common-target.def | 14 ++++++++++++++ > gcc/common/common-targhooks.cc | 9 +++++++++ > gcc/common/common-targhooks.h | 5 +++++ > gcc/doc/tm.texi | 10 ++++++++++ > gcc/doc/tm.texi.in | 1 + > gcc/gcc.cc | 4 ++++ > 6 files changed, 43 insertions(+)
Ping :) Ref： https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675786.html https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675787.html Best regards, Jin Ma
