[Bug target/97779] New: Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97779 Bug ID: 97779 Summary: Newest releases/gcc-10 cannot build because lack of PTA_CLDEMOTE Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: icenowy at aosc dot io Target Milestone: --- When building GCC commit 454702f5213a7a8b6b3581c29c817b952ce0f184 on x86-64 natively, I met this failure: ``` In file included from ./tm.h:26, from /var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/gencheck.c:23: /var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/config/i386/i386.h:2481:46: error: 'PTA_CLDEMOTE' was not declared in this scope; did you mean 'PTA_CLZERO'? 2481 | | PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE | PTA_WAITPKG; | ^~~~ | PTA_CLZERO /var/cache/acbs/build/acbs.ctuyh9m4/gcc/gcc/config/i386/i386.h:2480:24: warning: 'PTA_TREMONT' defined but not used [-Wunused-variable] 2480 | const wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB |^~~ ``` This seems to be a issue of commit 3ec6a380bda3d2193925e1c017ea2739476cc125 , which adds this macro to PTA_TREMONT.
[Bug rtl-optimization/97535] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535
--- Comment #3 from Icenowy Zheng ---
A minimal reproduction: (Compile with gcc -c -O1)
```
#include
#define SIZE 2181038080
extern char raw_buffer[SIZE];
void setRaw(const void *raw)
{
memcpy(raw_buffer, raw, SIZE);
}
```
[Bug rtl-optimization/97535] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #1 from Icenowy Zheng --- The problem is found to be trying to expand a memcpy() call with fixed length 2181038080. Handling of memcpy() expansion seem to be corrupted when len >= 2147483648. The length is mod with 2147483648, and then forced to expand. When a test program that contains a call to memcpy() with len 2147483648 is tried, it is "expanded" to nothing. The problematic thing seems to be aarch64_expand_cpymem() in master at config/aarch64/aarch64.c (aarch64_expand_movmem() in GCC 9), in which the variable n is declared with `int` (a 32-bit signed integer on both AArch64 LP64 and x86-64). Modify it to HOST_WIDE_INT seems to fix the problem.
[Bug rtl-optimization/97535] New: ICE when building xmrig on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535
Bug ID: 97535
Summary: ICE when building xmrig on AArch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: icenowy at aosc dot io
Target Milestone: ---
Created attachment 49425
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49425=edit
Preprocessed source file
When building xmrig on AArch64 with GCC 9.3.1, this file will trap cc1plus into
infinitely running.
I extracted the preprocessed source and then proceed with GCC master (commit
0a74a0e1a2d ("libstdc++: Fix custom clock in test")), and now it fails with
ICE:
/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp: In
member function 'void xmrig::RxDataset::setRaw(const void*)':
/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp:178:1:
error: unrecognizable insn:
(insn 80 79 81 4 (parallel [
(set (reg:V4SI 162)
(mem:V4SI (plus:DI (reg:DI 97)
(const_int 1024 [0x400])) [0 MEM
[(void *)raw_7(D)]+1024 S16 A8]))
(set (reg:V4SI 163)
(mem:V4SI (plus:DI (reg:DI 97)
(const_int 1040 [0x410])) [0 MEM
[(void *)raw_7(D)]+1040 S16 A8]))
])
"/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp":177:11
-1
(nil))
during RTL pass: vregs
/var/cache/acbs/build/acbs.6sxjqdht/xmrig-6.3.5/src/crypto/rx/RxDataset.cpp:178:1:
internal compiler error: in extract_insn, at recog.c:2295
0x82f9e8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/icenowy/git-repos/gcc/gcc/rtl-error.c:108
0x82fa04 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/icenowy/git-repos/gcc/gcc/rtl-error.c:116
0x82def9 extract_insn(rtx_insn*)
/home/icenowy/git-repos/gcc/gcc/recog.c:2295
0xe433b7 instantiate_virtual_regs_in_insn
/home/icenowy/git-repos/gcc/gcc/function.c:1656
0xe433b7 instantiate_virtual_regs
/home/icenowy/git-repos/gcc/gcc/function.c:1977
0xe433b7 execute
/home/icenowy/git-repos/gcc/gcc/function.c:2026
[Bug c/84475] New: pthread doesn't define _REENTRANT in preprocessor on riscv-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84475 Bug ID: 84475 Summary: pthread doesn't define _REENTRANT in preprocessor on riscv-linux Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: icenowy at aosc dot io Target Milestone: --- The newly introduced platform, riscv, doesn't have _REENTRANT defined when -pthread is appended.
[Bug libffi/84410] New: libffi doesn't support riscv now, but not disabled in configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84410 Bug ID: 84410 Summary: libffi doesn't support riscv now, but not disabled in configure.ac Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: icenowy at aosc dot io Target Milestone: --- The libffi library currently doesn't support UCB RISC-V architecture (both in the downstream copy and the upstream). However, in configure.ac it's not masked for riscv*-*-*, and when trying to build libgo it will try to build libffi and fail.
[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 --- Comment #12 from Icenowy Zheng --- (In reply to Wilco from comment #11) > (In reply to Icenowy Zheng from comment #10) > > In my environment (glibc 2.25, and both the building scripts of glibc and > > gcc have -fomit-frame-pointer automatically enabled), this bug is not fully > > resolved yet. > > > > With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With > > GCC 6.3.0 GDB cannot even work and segfault at unwind code in libgcc). > > > > However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the > > backtrace() function of glibc cannot work, and segfault at line 240 of > > libgcc/unwind-dw2.c . > > > > By reading the source code, I think the unwind code is still trying to get > > CFA from the register x29, and when debugging I found that the x29 register > > in the unwind context is 0 (because of -fomit-frame-pointer), so line 240 is > > dereferencing a NULL pointer, so it segfaulted. > > > > Maybe the behavior that accessing x29 register to get CFA is not correct? > > Well if everything built with -fomit-frame-pointer then it is definitely > wrong to read x29. Can you give more info similar to comment #3? I didn't remember a lot as this issue is already fixed in our build system by removing -fomit-frame-pointer. But I remember part of the stacktrace: _Unwind_GetGR(index=29) at libgcc/unwind-dw2.c:240 <= segfault here _Unwind_GetPtr(index=29) at libgcc/unwind-dw2.c:251 uw_update_context_1() at libgcc/unwind-dw2.c:1410 _Unwind_Backtrace() at libgcc/unwind.inc (line number forgot) backtrace() in libc.so.6
[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71951 Icenowy Zheng changed: What|Removed |Added CC||icenowy at aosc dot io --- Comment #10 from Icenowy Zheng --- In my environment (glibc 2.25, and both the building scripts of glibc and gcc have -fomit-frame-pointer automatically enabled), this bug is not fully resolved yet. With GCC upgraded to 6.4.0, GDB debugger started to work correctly. (With GCC 6.3.0 GDB cannot even work and segfault at unwind code in libgcc). However, if I still build GCC with -fomit-frame-pointer in CFLAGS, the backtrace() function of glibc cannot work, and segfault at line 240 of libgcc/unwind-dw2.c . By reading the source code, I think the unwind code is still trying to get CFA from the register x29, and when debugging I found that the x29 register in the unwind context is 0 (because of -fomit-frame-pointer), so line 240 is dereferencing a NULL pointer, so it segfaulted. Maybe the behavior that accessing x29 register to get CFA is not correct?
