[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from John David Anglin --- Should be fixed.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #14 from GCC Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:53fd0f5b1fd737a208c12909fa1188281cb370a3 commit r14-9482-g53fd0f5b1fd737a208c12909fa1188281cb370a3 Author: John David Anglin Date: Thu Mar 14 18:32:56 2024 + hppa: Fix REG+D address support before reload When generating PA 1.x code or code for GNU ld, floating-point accesses only support 5-bit displacements but integer accesses support 14-bit displacements. I mistakenly assumed reload could fix an invalid 14-bit displacement in a floating-point access but this is not the case. 2024-03-14 John David Anglin gcc/ChangeLog: PR target/114288 * config/pa/pa.cc (pa_legitimate_address_p): Don't allow 14-bit displacements before reload for modes that may use a floating-point load or store.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |14.0 Target||hppa
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #13 from dave.anglin at bell dot net ---
On 2024-03-10 12:15 a.m., law at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
>
> --- Comment #12 from Jeffrey A. Law ---
> Aren't we compiling for PA2.0? If so, shouldn't we have a full 14 bit offset
> support, even when a load/store hits the FP register file (feel free to
> correct
> me if I'm wrong, it's only been 20 years since I worked on this stuff ;-)
Unfortunately, the PA2.0 relocation for 14-bit offsets in floating-point loads
and stores is broken
and can't be used on linux. Works fine on hpux.
Needs to be fixed.
>
> So I don't really see why the offsets are an issue here.
At this time, we are limited to 5-bit offsets for floating-point loads and
stores.
>
>
> If we were compiling for PA1.0/PA1.1, then yes, there's a real issue, but it's
> with allowing the larger offsets as a legitimate address. That's lying to the
> compiler, reload in particular and as I said, it's ultimately going to
> backfire
> -- even with the workaround since you're going to have DImode loads/stores to
> the FP register file due to xmpyu or potentially even memcpy and friends. I
> already tried what you're doing years ago. It's doomed to failure.
>
> You might think this is a reload problem. But I'm far from convinced. It
> smells much more like a PA backend issue to me.
I think the problem is with pa_secondary_reload. There is code in
pa_emit_move_sequence
to handle reloads for for floating-point loads/stores from REG+D addresses but
it isn't being
used.
In non-pic code, the reloads appear to be handled correctly. In pic code,
reload doesn't know
how to handle a REG+D address where the REG contains the address of a
symbol_ref:
(insn 10 11 12 2 (set (reg/f:SI 146)
(mem/u/c:SI (lo_sum:SI (reg:SI 113)
(unspec:SI [
(symbol_ref:SI ("indirect_child") )
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 113)
(expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child") )
(nil
In theory, it seems to me reload could try reloading D to a register. The
offsets are limited to 14 bits
and the ldo instruction can handle that directly.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #12 from Jeffrey A. Law --- Aren't we compiling for PA2.0? If so, shouldn't we have a full 14 bit offset support, even when a load/store hits the FP register file (feel free to correct me if I'm wrong, it's only been 20 years since I worked on this stuff ;-) So I don't really see why the offsets are an issue here. If we were compiling for PA1.0/PA1.1, then yes, there's a real issue, but it's with allowing the larger offsets as a legitimate address. That's lying to the compiler, reload in particular and as I said, it's ultimately going to backfire -- even with the workaround since you're going to have DImode loads/stores to the FP register file due to xmpyu or potentially even memcpy and friends. I already tried what you're doing years ago. It's doomed to failure. You might think this is a reload problem. But I'm far from convinced. It smells much more like a PA backend issue to me.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #11 from Jeffrey A. Law --- The larger point is we don't just disable passes because they have a bug, or even multiple bugs. We need to do the right thing from an engineering standpoint, ie, actually debug the problem. In fact, this is a great example of why disabling would be a mistake. This bug is going to be easier to analyze than the python issue triggered by f-m-o or the m68k bootstrap issue. Had we disabled, we likely wouldn't have tripped over this issue.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #10 from Sam James --- Sure, that's fine (I would've CC'd you for your opinion if you weren't here already). I know you were reluctant already with the m68k PR, but figured this was different enough to suggest it given the other one is analysed at least. Understood.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #9 from Jeffrey A. Law --- Sam, no. That would be a big mistake.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #8 from Sam James --- We could flip the default for -ffold-mem-offsets for HPPA to off for now..
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #7 from John David Anglin --- Created attachment 57658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57658&action=edit Patch This change works around the reload issue for alpha.i and the reduced test case. In principle, this could also occur for SI and DI mode floating-point loads and stores but limiting them to 5-bit offsets is a big compromise. It probably would also break python builds as PR rtl-optimization/112415 still isn't fixed.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #6 from John David Anglin --- It looks to me like a bug in reload. Reload generates bogus reloads for insn 14 and deletes insn 10 which sets (reg/f:SI 146). But the bug was probably exposed by the change I made a few months ago to pa_legitimate_address_p. insn 14 needs reloading because the offset doesn't fit in 5 bits. The code in pa_emit_move_sequence to fix up invalid offsets in floating point loads and stores is not used. This backtrace points to the broken area of reload. (gdb) bt #0 pa_emit_move_sequence (operands=0xf7b02e08, mode=E_SImode, scratch_reg=0x0) at ../../gcc/gcc/config/pa/pa.cc:1924 #1 0x011366a8 in gen_movsi (operand0=0xf98f35e8, operand1=0xf98276a0) at ../../gcc/gcc/config/pa/pa.md:2141 #2 0x004a7070 in insn_gen_fn::operator() ( this=) at ../../gcc/gcc/recog.h:441 #3 emit_move_insn_1 (x=0xf98276a0, y=0xf98276a0) at ../../gcc/gcc/expr.cc:4551 #4 0x004b229c in gen_move_insn (x=0xf98276a0, y=0xf98f35e8) at ../../gcc/gcc/expr.cc:4741 #5 0x00843fe4 in gen_reload (out=, in=, opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS) at ../../gcc/gcc/reload1.cc:8637 #6 0x008442f0 in gen_reload (out=, in=, opnum=-108890464, type=RELOAD_FOR_OPERAND_ADDRESS) at ../../gcc/gcc/reload1.cc:8550 #7 0x00848914 in emit_input_reload_insns (chain=, rl=0x192ddf8 , old=, j=-108890464) at ../../gcc/gcc/reload1.cc:7527 #8 do_input_reload (chain=, rl=0xf98f35e8, j=-108890464) at ../../gcc/gcc/reload1.cc:7814 #9 0x00850698 in emit_reload_insns (chain=) at ../../gcc/gcc/reload1.cc:8002 #10 reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.cc:4543 --Type for more, q to quit, c to continue without paging-- #11 reload (first=, global=1) at ../../gcc/gcc/reload1.cc:1047 #12 0x0067c508 in do_reload () at ../../gcc/gcc/ira.cc:5985 #13 (anonymous namespace)::pass_reload::execute (this=) at ../../gcc/gcc/ira.cc:6161 #14 0x0079ef7c in execute_one_pass (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2646 #15 0x0079f894 in execute_pass_list_1 (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2755 #16 0x0079f8ac in execute_pass_list_1 (pass=0xf98276a0) at ../../gcc/gcc/passes.cc:2756 #17 0x0079f90c in execute_pass_list (fn=, pass=) at ../../gcc/gcc/passes.cc:2766 #18 0x003b9a8c in cgraph_node::expand (this=0xf98276a0) at ../../gcc/gcc/context.h:48 #19 cgraph_node::expand (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:1798 #20 0x003bbaa8 in expand_all_functions () at ../../gcc/gcc/cgraphunit.cc:2028 #21 symbol_table::compile (this=0xf98276a0) at ../../gcc/gcc/cgraphunit.cc:2402 #22 0x003bdc4c in symbol_table::compile (this=0x7) at ../../gcc/gcc/cgraphunit.cc:2315 #23 symbol_table::finalize_compilation_unit (this=0x7) at ../../gcc/gcc/cgraphunit.cc:2587 #24 0x008d137c in compile_file () at ../../gcc/gcc/toplev.cc:476 Will try to work around issue in pa_legitimate_address_p.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #5 from John David Anglin ---
This is what we have from reload with Sam's reduced test case:
(insn 9 103 123 2 (set (reg/f:SI 1 %r1)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child") "beta.c":18:32 53 {*pa.md:2656}
(nil))
(insn 123 9 11 2 (set (reg:SI 20 %r20 [113])
(reg/f:SI 1 %r1)) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 11 123 10 2 (set (reg:SI 1 %r1 [115])
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
(nil))
(note 10 11 12 2 NOTE_INSN_DELETED)
(insn 12 10 13 2 (set (reg/f:SI 20 %r20 [114])
(mem/u/c:SI (lo_sum:SI (reg:SI 1 %r1 [115])
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil)))
(insn 13 12 125 2 (set (reg:DF 68 %fr22 [116])
(mem/u/c:DF (reg/f:SI 20 %r20 [114]) [0 S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
(expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil)))
(insn 125 13 127 2 (set (reg:SI 20 %r20)
(const_int 32 [0x20])) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 127 125 128 2 (set (reg:SI 20 %r20)
(reg/f:SI 146)) "beta.c":18:32 42 {*pa.md:2195}
(nil))
(insn 128 127 14 2 (set (reg:SI 20 %r20)
(plus:SI (reg:SI 20 %r20)
(const_int 32 [0x20]))) "beta.c":18:32 120 {addsi3}
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 146)
(const_int 32 [0x20]))
(nil)))
(insn 14 128 116 2 (set (mem/c:DF (plus:SI (reg:SI 20 %r20)
(const_int -16 [0xfff0])) [1
indirect_child.cg.prop.fract+0 S8 A64])
(reg:DF 68 %fr22 [116])) "beta.c":18:32 75 {*pa.md:3866}
(nil))
In ira, we had:
(insn 9 103 11 2 (set (reg:SI 113)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref:SI ("indirect_child") "beta.c":18:32 53 {*pa.md:2656}
(nil))
(insn 11 9 10 2 (set (reg:SI 115)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2] "beta.c":18:32
53 {*pa.md:2656}
(nil))
(insn 10 11 12 2 (set (reg/f:SI 146)
(mem/u/c:SI (lo_sum:SI (reg:SI 113)
(unspec:SI [
(symbol_ref:SI ("indirect_child") )
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 113)
(expr_list:REG_EQUIV (symbol_ref:SI ("indirect_child") )
(nil
(insn 12 10 13 2 (set (reg/f:SI 114)
(mem/u/c:SI (lo_sum:SI (reg:SI 115)
(unspec:SI [
(symbol_ref/u:SI ("*.LC0") [flags 0x2])
] UNSPEC_DLTIND14R)) [0 S4 A32])) "beta.c":18:32 42
{*pa.md:2195}
(expr_list:REG_DEAD (reg:SI 115)
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC0") [flags 0x2])
(nil
(insn 13 12 14 2 (set (reg:DF 116)
(mem/u/c:DF (reg/f:SI 114) [0 S8 A64])) "beta.c":18:32 75
{*pa.md:3866}
(expr_list:REG_DEAD (reg/f:SI 114)
(expr_list:REG_EQUIV (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(nil
(insn 14 13 110 2 (set (mem/c:DF (plus:SI (reg/f:SI 146)
(const_int 16 [0x10])) [1 indirect_child.cg.prop.fract+0 S8
A64])
(reg:DF 116)) "beta.c":18:32 75 {*pa.md:3866}
(expr_list:REG_DEAD (reg:DF 116)
(nil)))
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #4 from Jeffrey A. Law --- BTW, the P4 designation is primarily because I suspected this would likely be a PA specific issue. If it turns out to be a generic problem, it would probably immediately bump to P1.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 John David Anglin changed: What|Removed |Added Last reconfirmed||2024-03-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from John David Anglin --- Confirmed with -fpie and -fpic.
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288
--- Comment #2 from Sam James ---
Reduced:
```
typedef long long bfd_vma;
typedef struct {
bfd_vma addr;
char name;
struct {
struct {
double fract;
} prop;
} cg;
} Sym;
Sym indirect_child;
int alpha_find_call_parent_insn;
bfd_vma alpha_find_call_parent_dest_pc;
void sym_lookup();
int hist_check_address();
Sym alpha_find_call_parent(bfd_vma p_highpc) {
bfd_vma pc;
indirect_child.cg.prop.fract = 1.0;
for (; pc < p_highpc; pc += 4)
switch (alpha_find_call_parent_insn) {
case 26:
sym_lookup(alpha_find_call_parent, &indirect_child);
alpha_find_call_parent_dest_pc =
((long long)alpha_find_call_parent_insn ^ 10) - 10;
hist_check_address();
sym_lookup(alpha_find_call_parent_dest_pc);
}
}
```
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug target/114288] [14 regression] ICE when building binutils-2.41 on hppa (extract_constrain_insn, at recog.cc:2713)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114288 --- Comment #1 from Sam James --- 'gcc -c alpha.i -O2' is enough for me to reproduce.
