: 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
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&action=edit
test case
This issue is seen with GCC 5.4.0 ship
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(l
IRMED
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&action=edit
test case
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&action=edit
test log of "riscv64-unknown-linux-gnu-g++ -v -save-temps -O2 riscv_cpp_test.c"
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.
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 :)
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
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&action=edit
minimal test case (test.c) and the preprocessed file (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #7 from Bin Meng ---
Any update about this issue?
: 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
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?
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
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?
14 matches
Mail list logo