public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug debug/103619] New: armeb ICE since r12-5833 @ 2021-12-08 12:47 clyon at gcc dot gnu.org 2021-12-08 12:57 ` [Bug debug/103619] " marxin at gcc dot gnu.org ` (4 more replies) 0 siblings, 5 replies; 6+ messages in thread From: clyon at gcc dot gnu.org @ 2021-12-08 12:47 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 Bug ID: 103619 Summary: armeb ICE since r12-5833 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r12-5833, I've noticed an ICE on armeb which prevents building the toolchain: during RTL pass: dwarf2 /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libbacktrace/dwarf.c: In function 'dwarf_lookup_pc': /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libbacktrace/dwarf.c:3885:1: internal compiler error: in dwf_cfa_reg, at dwarf2cfi.c:1139 3885 | } | ^ make[3]: Entering directory '/tmp/5562867_5.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-armeb-none-linux-gnueabihf/gcc3/armeb-none-linux-gnueabihf/libatomic' 0x8c97ca dwf_cfa_reg /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:1139 0x8ca275 dwarf2out_frame_debug_expr /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2131 0x8c9c27 dwarf2out_frame_debug_expr /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:1774 0x8cb21c dwarf2out_frame_debug /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2341 0x8cb21c scan_insn_after /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2700 0x8cd34c scan_trace /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2867 0x8cdfee create_cfi_notes /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:2907 0x8cdfee execute_dwarf2_frame /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:3285 0x8cdfee execute /tmp/5562867_5.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/dwarf2cfi.c:3773 GCC is configured with --target=armeb-none-linux-gnueabihf --disable-nls -- disable-libgomp --disable-libmudflap --disable-libcilkrts --enable-checking --enable-languages=c,c++,fortran --with-float=hard --enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16 Little-endian arm targets (arm-*) are still OK. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/103619] armeb ICE since r12-5833 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org @ 2021-12-08 12:57 ` marxin at gcc dot gnu.org 2021-12-08 14:38 ` abidh at gcc dot gnu.org ` (3 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: marxin at gcc dot gnu.org @ 2021-12-08 12:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC| |marxin at gcc dot gnu.org Last reconfirmed| |2021-12-08 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/103619] armeb ICE since r12-5833 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org 2021-12-08 12:57 ` [Bug debug/103619] " marxin at gcc dot gnu.org @ 2021-12-08 14:38 ` abidh at gcc dot gnu.org 2021-12-15 9:43 ` cvs-commit at gcc dot gnu.org ` (2 subsequent siblings) 4 siblings, 0 replies; 6+ messages in thread From: abidh at gcc dot gnu.org @ 2021-12-08 14:38 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 --- Comment #1 from Hafiz Abid qadeer <abidh at gcc dot gnu.org> --- I guess it is caused by the order of register from arm_dwarf_register_span being different in case of big endian. I will work on a fix once I can reproduce it. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/103619] armeb ICE since r12-5833 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org 2021-12-08 12:57 ` [Bug debug/103619] " marxin at gcc dot gnu.org 2021-12-08 14:38 ` abidh at gcc dot gnu.org @ 2021-12-15 9:43 ` cvs-commit at gcc dot gnu.org 2021-12-15 9:57 ` jakub at gcc dot gnu.org 2021-12-15 10:45 ` [Bug debug/103619] [12 Regression] " pinskia at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: cvs-commit at gcc dot gnu.org @ 2021-12-15 9:43 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 --- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:e75a0a03588977c8c758091f9b50d456a5f67227 commit r12-5994-ge75a0a03588977c8c758091f9b50d456a5f67227 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Dec 15 10:41:02 2021 +0100 dwarf2cfi: Improve cfa_reg comparisons [PR103619] On Tue, Dec 14, 2021 at 10:32:21AM -0700, Jeff Law wrote: > I think the attached testcase should trigger on c6x with -mbig-endian -O2 -g Thanks. Finally I see what's going on. c6x doesn't really need the CFA with span > 1 (and I bet neither does armbe), the only reason why dwf_cfa_reg is called is that the code in 13 cases just tries to compare the CFA against dwf_cfa_reg (some_reg). And that dwf_cfa_reg on some reg that usually isn't a CFA reg results in targetm.dwarf_register_span hook call, which on targets like c6x or armeb and others for some registers creates a PARALLEL with various REGs in it, then the loop with the assertion and finally operator== which just notes that the reg is different and fails. This seems compile time memory and time inefficient. The following so far untested patch instead adds an extra operator== and != for comparison of cfa_reg with rtx, which has the most common case where it is a different register number done early without actually invoking dwf_cfa_reg. This means the assertion in dwf_cfa_reg can stay as is (at least until some big endian target needs to have hard frame pointer or stack pointer with span > 1 as well). I've removed a different assertion there because it is redundant - dwf_regno already has exactly that assertion in it too. And I've included those 2 tweaks to avoid creating a REG in GC memory when we can use {stack,hard_frame}_pointer_rtx which is already initialized to the same REG we need by init_emit_regs. On Tue, Dec 14, 2021 at 03:05:37PM -0700, Jeff Law wrote: > So if someone is unfamiliar with the underlying issues here and needs to > twiddle dwarf2cfi, how are they supposed to know if they should compare > directly or use dwf_cfa_reg? Comparison without dwf_cfa_reg should be used whenever possible, because for registers which are never CFA related that won't call targetm.dwarf_register_span uselessly. The only comparisons with dwf_cfa_reg I've kept are the: regno = dwf_cfa_reg (XEXP (XEXP (dest, 0), 0)); if (cur_cfa->reg == regno) offset -= cur_cfa->offset; else if (cur_trace->cfa_store.reg == regno) offset -= cur_trace->cfa_store.offset; else { gcc_assert (cur_trace->cfa_temp.reg == regno); offset -= cur_trace->cfa_temp.offset; } and struct cfa_reg regno = dwf_cfa_reg (XEXP (dest, 0)); if (cur_cfa->reg == regno) offset = -cur_cfa->offset; else if (cur_trace->cfa_store.reg == regno) offset = -cur_trace->cfa_store.offset; else { gcc_assert (cur_trace->cfa_temp.reg == regno); offset = -cur_trace->cfa_temp.offset; } and there are 2 reasons for it: 1) there is an assertion, which guarantees it must compare equal to one of those 3 cfa related struct cfa_reg structs, so it must be some CFA related register (so, right now, targetm.dwarf_register_span shouldn't return non-NULL in those on anything but gcn) 2) it is compared 3 times in a row, so for the GCN case doing if (cur_cfa->reg == XEXP (XEXP (dest, 0), 0)) offset -= cur_cfa->offset; else if (cur_trace->cfa_store.reg == XEXP (XEXP (dest, 0), 0)) offset -= cur_trace->cfa_store.offset; else { gcc_assert (cur_trace->cfa_temp.reg == XEXP (XEXP (dest, 0), 0)); offset -= cur_trace->cfa_temp.offset; } could actually create more GC allocated garbage than the way it is written now. But doing it that way would work fine. I think for most of the comparisons even comparing with dwf_cfa_reg would work but be less compile time/memory efficient (e.g. those assertions that it is equal to some CFA related cfa_reg or in any spots where only the CFA related regs may appear in the frame related patterns). I'm aware just of a single spot where comparison with dwf_cfa_reg doesn't work (when the assert is in dwf_cfa_reg), that is the spot that was ICEing on your testcase, where we save arbitrary call saved register: if (REG_P (src) && REGNO (src) != STACK_POINTER_REGNUM && REGNO (src) != HARD_FRAME_POINTER_REGNUM && cur_cfa->reg == src) 2021-12-15 Jakub Jelinek <jakub@redhat.com> PR debug/103619 * dwarf2cfi.c (dwf_cfa_reg): Remove gcc_assert. (operator==, operator!=): New overloaded operators. (dwarf2out_frame_debug_adjust_cfa, dwarf2out_frame_debug_cfa_offset, dwarf2out_frame_debug_expr): Compare vars with cfa_reg type directly with REG rtxes rather than with dwf_cfa_reg results on those REGs. (create_cie_data): Use stack_pointer_rtx instead of gen_rtx_REG (Pmode, STACK_POINTER_REGNUM). (execute_dwarf2_frame): Use hard_frame_pointer_rtx instead of gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM). ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/103619] armeb ICE since r12-5833 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org ` (2 preceding siblings ...) 2021-12-15 9:43 ` cvs-commit at gcc dot gnu.org @ 2021-12-15 9:57 ` jakub at gcc dot gnu.org 2021-12-15 10:45 ` [Bug debug/103619] [12 Regression] " pinskia at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: jakub at gcc dot gnu.org @ 2021-12-15 9:57 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Hopefully fixed now. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug debug/103619] [12 Regression] armeb ICE since r12-5833 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org ` (3 preceding siblings ...) 2021-12-15 9:57 ` jakub at gcc dot gnu.org @ 2021-12-15 10:45 ` pinskia at gcc dot gnu.org 4 siblings, 0 replies; 6+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-12-15 10:45 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103619 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |12.0 Keywords| |ice-on-valid-code Summary|armeb ICE since r12-5833 |[12 Regression] armeb ICE | |since r12-5833 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-15 10:45 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-08 12:47 [Bug debug/103619] New: armeb ICE since r12-5833 clyon at gcc dot gnu.org 2021-12-08 12:57 ` [Bug debug/103619] " marxin at gcc dot gnu.org 2021-12-08 14:38 ` abidh at gcc dot gnu.org 2021-12-15 9:43 ` cvs-commit at gcc dot gnu.org 2021-12-15 9:57 ` jakub at gcc dot gnu.org 2021-12-15 10:45 ` [Bug debug/103619] [12 Regression] " pinskia at gcc dot gnu.org
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).