[Bug target/58442] bootstrapping vax crashes on NetBSD

2019-09-17 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also|

[Bug target/58442] bootstrapping vax crashes on NetBSD

2019-09-17 Thread coypu at sdf dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 coypu changed: What|Removed |Added CC||coypu at sdf dot org --- Comment #12 from coypu

[Bug target/58442] bootstrapping vax crashes on NetBSD

2018-09-06 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org ---

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-10-28 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #10 from Martin Husemann martin at netbsd dot org --- Matt Thomas suggested to go with the easy solution for now: protect the calls with MEM_P, i.e.: change the ! mode_dependent_address_p() in the bitfield patterns to (MEM_P(..) !

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-10-23 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #9 from Martin Husemann martin at netbsd dot org --- Please correct me if I am wrong, but in the bitfield cotexts in vax.md there are multiple places with similar constructs like: 219 (REG_P (operands[0]) 220|| !

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-10-21 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #7 from Martin Husemann martin at netbsd dot org --- I can reproduce the same crash on a different input file with a amd64 - vax cross compiler (so we can drop the theory that a miscompiled recog_1 function causes this).

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-10-21 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #8 from Martin Husemann martin at netbsd dot org --- And apparently same cause: ooops, bogus rtx mem attrs: 0x4 (subreg:SI (reg/v:DI 70 [ xtime ]) 4)

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-23 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #5 from Martin Husemann martin at netbsd dot org --- Just as a sanity check: I verified that the natively generated insn-recog.c is the same as one cross compiled on an amd64 host.

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-23 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #6 from Martin Husemann martin at netbsd dot org --- To verify, I instrumented get_mem_attrs: static inline struct mem_attrs * get_mem_attrs (const_rtx x) { struct mem_attrs *attrs; attrs = MEM_ATTRS (x); attrs = MEM_ATTRS

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-19 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #4 from Martin Husemann martin at netbsd dot org --- I stared at the assembly a bit more (but my vax fu is weak): we are in the last line of 216 #line 781 ../../gcc-4.8.1/gcc/config/vax/vax.md 217 ((INTVAL (operands[1]) == 8

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-18 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #3 from Martin Husemann martin at netbsd dot org --- 0x92c9fc recog_1(rtx, rtx, int*)+2:movab 0xff60(sp),sp 0x92ca01 recog_1(rtx, rtx, int*)+7: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,0xffd8(fp)

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-17 Thread martin at netbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #1 from Martin Husemann martin at netbsd dot org --- (gdb) x/i 0x0092cdb0 = 0x92cdb0 recog_1(rtx, rtx, int*)+950: movb 0x14(r0),r0 (gdb) info reg r0 0x4 4 r1 0x8 8 r2 0x0 0 r3

[Bug target/58442] bootstrapping vax crashes on NetBSD

2013-09-17 Thread jbg...@lug-owl.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de --- So r0 is waay off. As we're far into the function (950) and fiddling with r0, I guess this is the final part, preparing to return from here. An assembler dump of the whole function would