[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

2023-07-31 Thread bmeng.cn at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478

--- Comment #7 from Bin Meng  ---
Any update about this issue?

[Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

2023-06-29 Thread bmeng.cn at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478

Bug ID: 110478
   Summary: RISC-V multilib gcc zicsr in the -march causing
incorrect libgcc to be used
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmeng.cn at gmail dot com
  Target Milestone: ---

Using the prebuilt toolchain from kernel.org to test this.

$ cd /tmp
$ wget
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/13.1.0/x86_64-gcc-13.1.0-nolibc-riscv64-linux.tar.xz
$ tar xf x86_64-gcc-13.1.0-nolibc-riscv64-linux.tar.xz
$ cd /tmp/gcc-13.1.0-nolibc/riscv64-linux/bin
$ ./riscv64-linux-gcc -march=rv64gc -mabi=lp64 -print-libgcc-file-name
/tmp/gcc-13.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/13.1.0/lib64/lp64/libgcc.a
$ ./riscv64-linux-gcc -march=rv32gc -mabi=ilp32 -print-libgcc-file-name
/tmp/gcc-13.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/13.1.0/lib32/ilp32/libgcc.a

$ ./riscv64-linux-gcc -march=rv64gc_zicsr -mabi=lp64 -print-libgcc-file-name
/tmp/gcc-13.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/13.1.0/libgcc.a
$ ./riscv64-linux-gcc -march=rv32gc_zicsr -mabi=ilp32 -print-libgcc-file-name
/tmp/gcc-13.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/13.1.0/libgcc.a

As you can see from above, without "zicsr" in the "-march", the libgcc path
correctly reflects its multilib configuration, i.e.: 64-bit will link the
libgcc.a in the lib64 sub-directory.

But with "zicsr" in the "-march", the libgcc path is always the non-multilib
version.

The toolchain was configured by:

$ ./riscv64-linux-gcc -###
Using built-in specs.
COLLECT_GCC=./riscv64-linux-gcc
COLLECT_LTO_WRAPPER=/tmp/gcc-13.1.0-nolibc/riscv64-linux/bin/../libexec/gcc/riscv64-linux/13.1.0/lto-wrapper
Target: riscv64-linux
Configured with: /home/arnd/git/gcc/configure --host=x86_64-linux-gnu
--build=aarch64-linux --target=riscv64-linux --enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-13.1.0-nolibc/riscv64-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
--with-static-standard-libraries
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC) 


It seems this multilib bug was introduced when zicsr was introduced to RISC-V
GCC.

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

2023-06-29 Thread bmeng.cn at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478

--- Comment #2 from Bin Meng  ---
I am not sure I understand your comments.

Are you saying that this behavior of "zicsr" libgcc path in the multilib
configuration is intentional?

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

2023-06-29 Thread bmeng.cn at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478

--- Comment #4 from Bin Meng  ---
I can't get the build to pass with the same configure scripts on current GCC
HEAD :(

--host=x86_64-linux-gnu --build=aarch64-linux --target=riscv64-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-13.1.0-nolibc/riscv64-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
--with-static-standard-libraries

Error below:

Checking multilib configuration for libgcc...
make[2]: Entering directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
Makefile:183: ../.././gcc/libgcc.mvars: No such file or directory
make[2]: *** No rule to make target '../.././gcc/libgcc.mvars'.  Stop.
make[2]: Leaving directory '/home/bmeng/git/gcc/riscv64-linux/libgcc'
make[1]: *** [Makefile:12855: all-target-libgcc] Error 2

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

2023-06-30 Thread bmeng.cn at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478

--- Comment #6 from Bin Meng  ---
While I am figuring out the build failure, Palmer or Kito, are you able to
reproduce this libgcc bug with zicsr on the GCC HEAD?