[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 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?

[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

[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 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
: 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

[Bug other/94136] New: GCC doc for built-in function __builtin___clear_cache() not 100% correct

2020-03-11 Thread bmeng.cn at gmail dot com
: 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

[Bug c/91713] New: GP linker relaxation is not performed with -nostdlib

2019-09-09 Thread bmeng.cn at gmail dot com
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

[Bug target/91420] relocation truncated to fit: R_RISCV_HI20 against `.LC0' with GCC 8.2/8.3 with "-O2" on RISC-V

2019-08-11 Thread bmeng.cn at gmail dot com
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

2019-08-11 Thread bmeng.cn at gmail dot com
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

2019-08-11 Thread bmeng.cn at gmail dot com
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

2019-08-11 Thread bmeng.cn at gmail dot com
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 attac

[Bug c/88966] Indirect stringification of "linux" produces "1"

2019-01-21 Thread bmeng.cn at gmail dot com
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

[Bug c/88966] New: Indirect stringification of "linux" produces "1"

2019-01-21 Thread bmeng.cn at gmail dot com
3 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 Ub

[Bug c/87793] New: GCC reports error when compiling with "-fpic -Os -g"

2018-10-29 Thread bmeng.cn at gmail dot com
iority: 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) #