[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478 --- Comment #7 from Bin Meng --- Any update about this issue?
[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
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?
[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
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
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 driver/110478] New: RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used
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 other/94136] New: GCC doc for built-in function __builtin___clear_cache() not 100% correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94136 Bug ID: 94136 Summary: GCC doc for built-in function __builtin___clear_cache() not 100% correct Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bmeng.cn at gmail dot com Target Milestone: --- See https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html It says: "Built-in Function: void __builtin___clear_cache (void *begin, void *end) This function is used to flush the processor’s instruction cache for the region of memory between begin inclusive and end exclusive. Some targets require that the instruction cache be flushed, after modifying memory containing code, in order to obtain deterministic behavior. If the target does not require instruction cache flushes, __builtin___clear_cache has no effect. Otherwise either instructions are emitted in-line to clear the instruction cache or a call to the __clear_cache function in libgcc is made." When I was looking at the RISC-V port, I assumed the GCC RISC-V would replace the call to __builtin___clear_cache() with __clear_cache() as the document says, but it does not. I raised this to RISC-V GCC and had a discussion with Andrew at: https://github.com/riscv/riscv-gcc/issues/178 As Andrew suggested, the doc should be improved to avoid such confusion.
[Bug c/91713] New: GP linker relaxation is not performed with -nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91713
Bug ID: 91713
Summary: GP linker relaxation is not performed with -nostdlib
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bmeng.cn at gmail dot com
Target Milestone: ---
See the following test case
$ cat test.c
int a = 1;
int main()
{
return a;
}
Building the test case with "-nostdlib" seems to disable the GP linker
relaxation:
$ riscv64-unknown-linux-gnu-gcc test.c -o test -nostdlib
$ riscv64-unknown-linux-gnu-objdump -d test | grep gp
But if we compile test.c without "-nostdlib":
$ riscv64-unknown-linux-gnu-gcc test.c -o test
$ riscv64-unknown-linux-gnu-objdump -d test | grep gp
103bc: 2197auipc gp,0x2
103c0: 46418193addigp,gp,1124 # 12820
<__global_pointer$>
1041c: 8141c783lbu a5,-2028(gp) # 12034 <_edata>
1042a: 80f18a23sb a5,-2028(gp) # 12034 <_edata>
10440: 8101a783lw a5,-2032(gp) # 12030
[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 --- Comment #5 from Bin Meng --- Thanks Andrew. That makes sense! I wonder whether there is a way to teach GCC not to generate code for such radical optimization that it can't relocate when using "-O2", on all architectures :)
[Bug c++/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 --- Comment #3 from Bin Meng --- Thanks Andrew for the quick response! Agreed, that it's caused by the current code model limitation of RISC-V. However I was wondering why passing "-O0" could make the linking pass.
[Bug c++/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 --- Comment #1 from Bin Meng --- Created attachment 46701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46701=edit test log of "riscv64-unknown-linux-gnu-g++ -v -save-temps -O2 riscv_cpp_test.c"
[Bug c++/91420] New: relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91420 Bug ID: 91420 Summary: relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 on RISC-V Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bmeng.cn at gmail dot com Target Milestone: --- Created attachment 46700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46700=edit test case Please use attached test case "riscv_cpp_test.c" to trigger the bug. $ riscv64-unknown-linux-gnu-g++ -O2 riscv_cpp_test.c /tmp/ccCpODP4.o: In function `.L0 ': riscv_cpp_test.c:(.text.startup+0x4): relocation truncated to fit: R_RISCV_HI20 against `.LC0' /share/toolchains/riscv/lib/gcc/riscv64-unknown-linux-gnu/8.2.0/../../../../riscv64-unknown-linux-gnu/bin/ld: final link failed: Symbol needs debug section which does not exist collect2: error: ld returned 1 exit status Workaround: using "-O0" makes the linking procedure happy. $ riscv64-unknown-linux-gnu-g++ -O0 riscv_cpp_test.c
[Bug c/88966] Indirect stringification of "linux" produces "1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966 --- Comment #2 from Bin Meng --- (In reply to Dimitar Dimitrov from comment #1) > The "linux" is a predefined macro: > > $ $ gcc -E -dM - #define linux 1 > > Looks like by-design to me. Indeed "linux" is a predefined macro. But why does str(linux) and stringify(linux) give different results?
[Bug c/88966] New: Indirect stringification of "linux" produces "1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966 Bug ID: 88966 Summary: Indirect stringification of "linux" produces "1" Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bmeng.cn at gmail dot com Target Milestone: --- Created attachment 45487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45487=edit test case This issue is seen with GCC 5.4.0 shipped by Ubuntu 16.04, but is also reproducible with GCC 7.3.0 and 8.1.0. Use attached test case (test.c) to reproduce. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) $ gcc test.c -o test $ ./test case 1: 1 case 2: vmlinux case 3: linux4.20 case 4: weird 1 ? case 5: linux It looks the indirect stringification (two levels) has special handling of "linux". Doing just one level (see case 5) works fine.
[Bug c/87793] New: GCC reports error when compiling with "-fpic -Os -g"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793
Bug ID: 87793
Summary: GCC reports error when compiling with "-fpic -Os -g"
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bmeng.cn at gmail dot com
Target Milestone: ---
Created attachment 44921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44921=edit
minimal test case (test.c) and the preprocessed file (test.i)
# Command line to call compiler
$ /share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc -march=i386
-m32 -c test.c -o test.o -fpic -Os -g --save-temps -v
# Output
Using built-in specs.
COLLECT_GCC=/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc
Target: i386-linux
Configured with: /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-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
: (reconfigured) /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-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
Thread model: single
gcc version 8.1.0 (GCC)
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-E -quiet -v -iprefix
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/
test.c -march=i386 -m32 -fpic -g -fworking-directory -Os -fpch-preprocess -o
test.i
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include-fixed"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-fpreprocessed test.i -quiet -dumpbase test.c -march=i386 -m32 -auxbase-strip
test.o -g -Os -version -fpic -o test.s
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5b6be85f431a859ca20ca7e588057ee0
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/bin/as
-v --32 -o test.o test.s
GNU assembler version 2.30 (i386-linux) using BFD version (GNU Binutils) 2.30
test.s: Assembler messages:
test.s:715: Error: junk at end of line, first unrecognized character is `@'
test.s:760: Error: junk at end of line, first unrecognized character is `@'
test.s:715: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.u_boot_list_2_fit_loadable_1 section}
test.s:760: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.
