public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
@ 2023-06-29 8:02 bmeng.cn at gmail dot com
2023-06-29 8:07 ` [Bug target/110478] " pinskia at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: bmeng.cn at gmail dot com @ 2023-06-29 8:02 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
@ 2023-06-29 8:07 ` pinskia at gcc dot gnu.org
2023-06-29 8:25 ` bmeng.cn at gmail dot com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-29 8:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|driver |target
Target| |Riscv
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is an idea pf having a compatible multilib.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
2023-06-29 8:07 ` [Bug target/110478] " pinskia at gcc dot gnu.org
@ 2023-06-29 8:25 ` bmeng.cn at gmail dot com
2023-06-29 8:29 ` kito at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: bmeng.cn at gmail dot com @ 2023-06-29 8:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #2 from Bin Meng <bmeng.cn at gmail dot com> ---
I am not sure I understand your comments.
Are you saying that this behavior of "zicsr" libgcc path in the multilib
configuration is intentional?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
2023-06-29 8:07 ` [Bug target/110478] " pinskia at gcc dot gnu.org
2023-06-29 8:25 ` bmeng.cn at gmail dot com
@ 2023-06-29 8:29 ` kito at gcc dot gnu.org
2023-06-29 16:26 ` bmeng.cn at gmail dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kito at gcc dot gnu.org @ 2023-06-29 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
Kito Cheng <kito at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kito at gcc dot gnu.org
--- Comment #3 from Kito Cheng <kito at gcc dot gnu.org> ---
I've fix few multilib issue on linux, however it's unfortunately fixed after
GCC 13.1 release...could you try trunk or releases/gcc-13 branch to see if that
issue resolved?
https://github.com/gcc-mirror/gcc/commit/6f0eb99c9bda726f953bdbe06dd3489a26af2823
https://github.com/gcc-mirror/gcc/commit/49d596e90deedbe9c7a1aa5824fb484fe3ad3193
https://github.com/gcc-mirror/gcc/commit/554aabc26786891ffb4d542c359eca0cef407ed1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
` (2 preceding siblings ...)
2023-06-29 8:29 ` kito at gcc dot gnu.org
@ 2023-06-29 16:26 ` bmeng.cn at gmail dot com
2023-06-29 22:54 ` palmer at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: bmeng.cn at gmail dot com @ 2023-06-29 16:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #4 from Bin Meng <bmeng.cn at gmail dot com> ---
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
` (3 preceding siblings ...)
2023-06-29 16:26 ` bmeng.cn at gmail dot com
@ 2023-06-29 22:54 ` palmer at gcc dot gnu.org
2023-06-30 13:44 ` bmeng.cn at gmail dot com
2023-07-31 7:22 ` bmeng.cn at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: palmer at gcc dot gnu.org @ 2023-06-29 22:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
palmer at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palmer at gcc dot gnu.org
--- Comment #5 from palmer at gcc dot gnu.org ---
(In reply to Bin Meng from comment #4)
> 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
It's building for me using riscv-gnu-toolchain and 070a6bf0bdc ("Update
documentation to clarify a GCC extension [PR c/77650]"). If the failure is
still reproducing on a HEAD can you give me a pointer to the exact commit?
Also might be better to put that in a different bug, it's probably not the same
issue.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
` (4 preceding siblings ...)
2023-06-29 22:54 ` palmer at gcc dot gnu.org
@ 2023-06-30 13:44 ` bmeng.cn at gmail dot com
2023-07-31 7:22 ` bmeng.cn at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: bmeng.cn at gmail dot com @ 2023-06-30 13:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #6 from Bin Meng <bmeng.cn at gmail dot com> ---
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
` (5 preceding siblings ...)
2023-06-30 13:44 ` bmeng.cn at gmail dot com
@ 2023-07-31 7:22 ` bmeng.cn at gmail dot com
6 siblings, 0 replies; 8+ messages in thread
From: bmeng.cn at gmail dot com @ 2023-07-31 7:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #7 from Bin Meng <bmeng.cn at gmail dot com> ---
Any update about this issue?
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-07-31 7:22 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-29 8:02 [Bug driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used bmeng.cn at gmail dot com
2023-06-29 8:07 ` [Bug target/110478] " pinskia at gcc dot gnu.org
2023-06-29 8:25 ` bmeng.cn at gmail dot com
2023-06-29 8:29 ` kito at gcc dot gnu.org
2023-06-29 16:26 ` bmeng.cn at gmail dot com
2023-06-29 22:54 ` palmer at gcc dot gnu.org
2023-06-30 13:44 ` bmeng.cn at gmail dot com
2023-07-31 7:22 ` bmeng.cn at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).