On Sat, 22 Feb 2025 02:19:03 PST (-0800), ji...@linux.alibaba.com wrote:
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 again :)
Is there any comment on this patches?
Not yet, I've got them open but I haven't had time to figure out the
paths yet. I know we screwed this up the first time and need to do
something, I'm just not really quite sure what the right answer is yet.
Best regards,
Jin Ma
Ref：
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675786.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675787.html
