[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 Bernd Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bernd Schmidt --- I looked at it and decided it's probably fine.
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #5 from Bernd Schmidt --- Ah, sorry Jim, I already had a patch. Ramana pointed out this bug but I didn't expect anyone else to actually investigate it. The overflow case can only occur in a failure case if the operand can't be renamed, so I've chosen to just record that fact. Someone might want to take a look at the aarch64 backend to see if it needs to take the new "failed" bit into account.
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 --- Comment #4 from Bernd Schmidt --- Author: bernds Date: Tue Nov 17 21:20:20 2015 New Revision: 230499 URL: https://gcc.gnu.org/viewcvs?rev=230499=gcc=rev Log: PR target/66785 * regrename.c (record_operand_use): Keep track of failed operands and stop appending if we see any. * regrename.h (struct operand_rr_info): Add a failed field and shrink n_chains to short. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c trunk/gcc/regrename.h
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- The operand_rr_info struct has arrays sized by MAX_REGS_PER_ADDRESS. regrename is calling record_operand_use for a write to an operand. It is also calling record_operand_use when a use (read or write) overlaps an earlier write. Hence a mem operand using an address with N regs can overlap N previous writes explaining the use of MAX_REGS_PER_ADDRESS. However, we can also have an operand that is N-regs wide that can overlap N previous 1-reg wide writes. Thus, we need to be able to handle the number of regs in the widest possible mode also. If we can have multiword regs used inside an address, things get even more complicated, but that isn't an issue at the moment. So instead of using just MAX_REGS_PER_ADDRESS, we need here something like #define OPERAND_RR_INFO_ARRAY_SIZE\ MAX (MAX_REGS_PER_ADDRESS, \ (MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT) / MIN_UNITS_PER_WORD) Unfortunately, this increases the array size from 2 to 16 for aarch64, as the widest mode is CXImode which takes 16 registers. This change may be wasting too much memory to be useful. This only affects the ports that have their own target dependent regrename pass though, which is only c6x and aarch64 at the moment. I suspect that we only need an array size of 4 for arm, as the widest instructions operate on 4 registers at a time, but I don't see an obvious way to get that info without adding another macro. I don't see any obvious uses of the chains member in operand_rr_info. The c6x and aarch64 ports are only using the heads member. So we could partially offset the memory size increase by dropping the chains member. Or maybe we can modify mode creation to avoid getting the CXI mode, as we don't need it. It is created automatically because we define XI as an 8-wide integer mode. Without CXImode the widest modes are only 8 registers wide. Combined with the removal of the chains member we are only doubling the size of this structure.
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 --- Comment #3 from Jim Wilson --- Created attachment 36705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36705=edit untested patch that may be wasting memory
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785 James Greenhalgh changed: What|Removed |Added Keywords||ice-on-valid-code Target|aarch64 |aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-16 Ever confirmed|0 |1
[Bug target/66785] internal compiler error in record_operand_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785
James Greenhalgh changed:
What|Removed |Added
Attachment #35920|0 |1
is obsolete||
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #1 from James Greenhalgh ---
Created attachment 36341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36341=edit
Reduced testcase without Undefined Behaviour
Confirmed with the testcase updated to avoid Undefined Behaviour.
It isn't immediately clear what is going wrong here, the ICE occurs before any
of the cortex-a57-fma-steering analysis kicks in, which implies an issue in the
generic register rename analysis code. The assert trips on this line:
gcc_assert (cur_operand->n_chains < MAX_REGS_PER_ADDRESS);
When handling this rtx:
(insn 403 78 417 4 (set (mem:XI (post_inc:DI (reg:DI 17 x17 [orig:205
ivtmp.18 ] [205])) [4 MEM[(float *)vectp_pretmp.12_54]+0 S64 A32])
(unspec:XI [
(reg:XI 32 v0 [orig:165 vect_array.14 ] [165])
(unspec:V4SF [
(const_int 0 [0])
] UNSPEC_VSTRUCTDUMMY)
] UNSPEC_ST4)) error.c:20 2372 {aarch64_simd_st4v4sf}
(expr_list:REG_INC (reg:DI 17 x17 [orig:205 ivtmp.18 ] [205])
(nil)))
In this case n_chains is either 2 or 3 and MAX_REGS_PER_ADDRESS for aarch64 is
set to 2, so we trip the assert.
I don't know regrename at all, so I'm not sure how we get in to this situation.
