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).