Hi Jin: Thanks for heads up:)
Hi Jeff: I've rebased that on the trunk and everything seems right, do you think it's OK for the trunk? On Mon, May 19, 2025 at 2:35 PM Jin Ma <ji...@linux.alibaba.com> wrote: > On Sun, 16 Mar 2025 11:23:07 -0600, Jeff Law wrote: > > > > > > On 3/10/25 2:26 AM, Kito Cheng wrote: > > > This patch fixes the multilib_os_dir and multiarch_dir for those > targets > > > that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB > hook > > > only update/fix the multilib_dir but not the multilib_os_dir and > multiarch_dir, > > > so the multilib_os_dir and multiarch_dir are not set correctly for > those targets. > > Thankfully only RISC-V defines TARGET_COMPUTE_MULTILIB. Though that may > > be an argument we should look to avoid whatever magic we're doing in > there. > > > > > > > > > > Use RISC-V linux target (riscv64-unknown-linux-gnu) as an example: > > > > > > ``` > > > $ riscv64-unknown-linux-gnu-gcc -print-multi-lib > > > .; > > > lib32/ilp32;@march=rv32imac@mabi=ilp32 > > > lib32/ilp32d;@march=rv32imafdc@mabi=ilp32d > > > lib64/lp64;@march=rv64imac@mabi=lp64 > > > lib64/lp64d;@march=rv64imafdc@mabi=lp64d > > > ``` > > > > > > If we use the exactly same -march and -mabi options to compile a > source file, > > > the multilib_os_dir and multiarch_dir are set correctly: > > > > > > ``` > > > $ riscv64-unknown-linux-gnu-gcc -print-multi-os-directory > -march=rv64imafdc -mabi=lp64d > > > ../lib64/lp64d > > > $ riscv64-unknown-linux-gnu-gcc -print-multi-directory > -march=rv64imafdc -mabi=lp64d > > > lib64/lp64d > > > ``` > > > > > > However if we use the -march=rv64imafdcv -mabi=lp64d option to compile > a source > > > file, the multilib_os_dir and multiarch_dir are not set correctly: > > > ``` > > > $ riscv64-unknown-linux-gnu-gcc -print-multi-os-directory > -march=rv64imafdc -mabi=lp64d > > > lib64/lp64d > > > $ riscv64-unknown-linux-gnu-gcc -print-multi-directory > -march=rv64imafdc -mabi=lp64d > > > lib64/lp64d > > > ``` > > > > > > That's because the TARGET_COMPUTE_MULTILIB hook only update/fix the > multilib_dir > > > but not the multilib_os_dir, so the multilib_os_dir is blank and will > use same > > > value as multilib_dir, but that is not correct. > > > > > > So we introduce second chance to fix the multilib_os_dir if it's not > set, we do > > > also try to fix the multiarch_dir, because it may also not set > correctly if > > > multilib_os_dir is not set. > > > > > > Changes since v1: > > > - Fix non-multilib build. > > > - Fix fix indentation. > > > > > > gcc/ChangeLog: > > > > > > * gcc.c (find_multilib_os_dir_by_multilib_dir): New. > > > (set_multilib_dir): Fix multilib_os_dir and multiarch_dir > > > if multilib_os_dir is not set. > > Given the fact this code is shared and I don't have a good handle on its > > behavior and how the change potentially affects other targets, I'm > > inclined to ask for this to wait for gcc-16 development to open and > > backport into gcc-15.2 after soak time on the trunk. > > > > Jeff > > Hi,I think this patch is essential. Can we proceed to push it to the trunk > now? > > Best regards, > Jin Ma
