[Bug target/58442] bootstrapping vax crashes on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=58901 Resolution|--- |FIXED --- Comment #13 from Eric Gallager --- (In reply to coypu from comment #12) > I think this ticket can be closed. > all the vax code with mode_dependent_address_p already checks that it's > MEM_P like suggested by matt thomas. > > > I can almost complete a build with the patch in #58901, with the other > unfixed bug being in binutils rather than GCC :-) ok, closing then
[Bug target/58442] bootstrapping vax crashes on NetBSD
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 --- I think this ticket can be closed. all the vax code with mode_dependent_address_p already checks that it's MEM_P like suggested by matt thomas. I can almost complete a build with the patch in #58901, with the other unfixed bug being in binutils rather than GCC :-)
[Bug target/58442] bootstrapping vax crashes on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #11 from Eric Gallager --- (In reply to Martin Husemann from comment #10) > 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(..) && ! mode_dependent_address_p(...)) > > With this change, a NetBSD kernel can be compiled (but does not yet boot), > and bootstrap goes way further along (will file another ticket for the next > obstacle). Did you ever file that other ticket?
[Bug target/58442] bootstrapping vax crashes on NetBSD
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(..) ! mode_dependent_address_p(...)) With this change, a NetBSD kernel can be compiled (but does not yet boot), and bootstrap goes way further along (will file another ticket for the next obstacle).
[Bug target/58442] bootstrapping vax crashes on NetBSD
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|| ! mode_dependent_address_p (XEXP (operands[0], 0), 221MEM_ADDR_SPACE (operands[0]) If I read the code correctly, MEM_ADDR_SPACE() might only be called if MEM_P() is true. The expression at hand is a SUBREG, so neither REG_P() nor MEM_P() is true, and we end up invoking MEM_ADDR_SPACE() and should cause a call to rtl_check_failed_code1(), causing an internal error and abort. No clue why that fails (and how). I do not understand VAX good enough, but as THE cisc arch would expect the moves generated here to work for subregs as well - so maybe we need to check for REG_P() || SUBREG_P(), where SUBREG_P would be new (GET_CODE(X) == SUBRECT)?
[Bug target/58442] bootstrapping vax crashes on NetBSD
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
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
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
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 (x);
if (!attrs) {
attrs = mode_mem_attrs[(int) GET_MODE (x)];
if ((unsigned long)attrs 1024) {
fprintf(stderr, ooops, mode_mem_attrs are bogus: %p mode %d\n, attrs,
G$
debug_rtx(x);
}
} else if ((unsigned long)attrs 1024) {
fprintf(stderr, ooops, bogus rtx mem attrs: %p\n, attrs);
debug_rtx(x);
}
return attrs;
}
and indeed this fires:
ooops, bogus rtx mem attrs: 0x4
(subreg:SI (reg/v:DI 71 [ __s ]) 4)
In file included from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/bits/locale_facets_nonio.h:1903:0,
from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/locale:41,
from
../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/locale-inst.cc:29:
...
[Bug target/58442] bootstrapping vax crashes on NetBSD
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 || INTVAL (operands[1]) == 16) 218 INTVAL (operands[2]) % INTVAL (operands[1]) == 0 219 (REG_P (operands[0]) 220|| ! mode_dependent_address_p (XEXP (operands[0], 0), 221MEM_ADDR_SPACE (operands[0]) and doing: 0x92cda2 recog_1(rtx, rtx, int*)+936: movl *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,r0 this is r0 = operands[0] MEM_ADDR_SPACE(RTX) is get_mem_attrs (RTX)-addrspace) so we do the call: 0x92cda9 recog_1(rtx, rtx, int*)+943: pushl r0 0x92cdab recog_1(rtx, rtx, int*)+945: calls $0x1,0x92c99e get_mem_attrs(const_rtx) and apparently get_mem_attrs(operand[0]) returned 4, which we then deref to -addrspace and crash.
[Bug target/58442] bootstrapping vax crashes on NetBSD
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) 0x92ca09 recog_1(rtx, rtx, int*)+15: movl 0x4(ap),r0 0x92ca0d recog_1(rtx, rtx, int*)+19: movl 0x4(r0),0xffdc(fp) 0x92ca12 recog_1(rtx, rtx, int*)+24: movw *0xffdc(fp),r0 0x92ca16 recog_1(rtx, rtx, int*)+28: movzwl r0,r0 0x92ca19 recog_1(rtx, rtx, int*)+31: movl r0,0xff64(fp) 0x92ca1e recog_1(rtx, rtx, int*)+36: cmpl 0xff64(fp),$0x2c 0x92ca23 recog_1(rtx, rtx, int*)+41: beql 0x92ca60 recog_1(rtx, rtx, int*)+102 0x92ca25 recog_1(rtx, rtx, int*)+43: cmpl 0xff64(fp),$0x007a 0x92ca2e recog_1(rtx, rtx, int*)+52: bneq 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca30 recog_1(rtx, rtx, int*)+54: brw 0x92cbe1 recog_1(rtx, rtx, int*)+487 0x92ca33 recog_1(rtx, rtx, int*)+57: pushl $0x6 0x92ca35 recog_1(rtx, rtx, int*)+59: pushl 0xffdc(fp) 0x92ca38 recog_1(rtx, rtx, int*)+62: calls $0x2,0x6715e8 nonimmediate_operand(rtx_def*, machine_mode) 0x92ca3f recog_1(rtx, rtx, int*)+69: clrb 0xff6b(fp) 0x92ca43 recog_1(rtx, rtx, int*)+73: tstl r0 0x92ca45 recog_1(rtx, rtx, int*)+75: beql 0x92ca4c recog_1(rtx, rtx, int*)+82 0x92ca47 recog_1(rtx, rtx, int*)+77: movb $0x1,0xff6b(fp) 0x92ca4c recog_1(rtx, rtx, int*)+82: tstb 0xff6b(fp) 0x92ca50 recog_1(rtx, rtx, int*)+86: bneq 0x92ca55 recog_1(rtx, rtx, int*)+91 0x92ca52 recog_1(rtx, rtx, int*)+88: brw 0x92df46 recog_1(rtx, rtx, int*)+5452 0x92ca55 recog_1(rtx, rtx, int*)+91: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca5d recog_1(rtx, rtx, int*)+99: brw 0x92cf4a recog_1(rtx, rtx, int*)+1360 0x92ca60 recog_1(rtx, rtx, int*)+102: pushl $0x6 0x92ca62 recog_1(rtx, rtx, int*)+104: pushl 0xffdc(fp) 0x92ca65 recog_1(rtx, rtx, int*)+107: calls $0x2,0x66d802 push_operand(rtx_def*, machine_mode) 0x92ca6c recog_1(rtx, rtx, int*)+114: clrb 0xff6c(fp) 0x92ca70 recog_1(rtx, rtx, int*)+118: tstl r0 0x92ca72 recog_1(rtx, rtx, int*)+120: beql 0x92ca79 recog_1(rtx, rtx, int*)+127 0x92ca74 recog_1(rtx, rtx, int*)+122: movb $0x1,0xff6c(fp) 0x92ca79 recog_1(rtx, rtx, int*)+127: tstb 0xff6c(fp) 0x92ca7d recog_1(rtx, rtx, int*)+131: beql 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92ca7f recog_1(rtx, rtx, int*)+133: movl 0xffdc(fp),*0xef3cfc _GLOBAL_OFFSET_TABLE_+1548 0x92ca87 recog_1(rtx, rtx, int*)+141: movl 0x4(ap),r0 0x92ca8b recog_1(rtx, rtx, int*)+145: movl 0x8(r0),0xffdc(fp) 0x92ca90 recog_1(rtx, rtx, int*)+150: movl 0xffdc(fp),r0 0x92ca94 recog_1(rtx, rtx, int*)+154: movb 0x2(r0),r0 0x92ca98 recog_1(rtx, rtx, int*)+158: movzbl r0,r0 0x92ca9b recog_1(rtx, rtx, int*)+161: cmpl r0,$0x6 0x92ca9e recog_1(rtx, rtx, int*)+164: bneq 0x92caac recog_1(rtx, rtx, int*)+178 0x92caa0 recog_1(rtx, rtx, int*)+166: movw *0xffdc(fp),r0 0x92caa4 recog_1(rtx, rtx, int*)+170: movzwl r0,r0 0x92caa7 recog_1(rtx, rtx, int*)+173: cmpl r0,$0x32 0x92caaa recog_1(rtx, rtx, int*)+176: beql 0x92cab8 recog_1(rtx, rtx, int*)+190 0x92caac recog_1(rtx, rtx, int*)+178: movl 0x4(ap),r0 0x92cab0 recog_1(rtx, rtx, int*)+182: movl 0x4(r0),0xffdc(fp) 0x92cab5 recog_1(rtx, rtx, int*)+187: brw 0x92ca33 recog_1(rtx, rtx, int*)+57 0x92cab8 recog_1(rtx, rtx, int*)+190: movl 0xffdc(fp),r0 0x92cabc recog_1(rtx, rtx, int*)+194: movl 0x4(r0),0xffe0(fp) 0x92cac1 recog_1(rtx, rtx, int*)+199: pushl $0x6 0x92cac3 recog_1(rtx, rtx, int*)+201: pushl 0xffe0(fp) 0x92cac6 recog_1(rtx, rtx, int*)+204: calls $0x2,0x671620 register_operand(rtx_def*, machine_mode) 0x92cacd recog_1(rtx, rtx, int*)+211: clrb 0xff6d(fp) 0x92cad1 recog_1(rtx, rtx, int*)+215: tstl r0 0x92cad3 recog_1(rtx, rtx, int*)+217: beql 0x92cada recog_1(rtx, rtx, int*)+224 0x92cad5 recog_1(rtx, rtx, int*)+219: movb $0x1,0xff6d(fp) 0x92cada recog_1(rtx, rtx, int*)+224: tstb 0xff6d(fp) 0x92cade recog_1(rtx, rtx, int*)+228: beql 0x92caf0 recog_1(rtx, rtx, int*)+246 0x92cae0 recog_1(rtx, rtx, int*)+230: movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,r0 0x92cae7 recog_1(rtx, rtx, int*)+237: addl2 $0x4,r0 0x92caea recog_1(rtx, rtx, int*)+240: movl 0xffe0(fp),(r0) 0x92caee recog_1(rtx, rtx, int*)+244: brb 0x92cafc recog_1(rtx, rtx, int*)+258 0x92caf0 recog_1(rtx, rtx, int*)+246: movl
[Bug target/58442] bootstrapping vax crashes on NetBSD
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 0xf0c308 15778568 r4 0x0 0 r5 0x0 0 r6 0x9e 158 r7 0x7f7d6c72 2138926194 r8 0x7f7ca000 2138873856 r9 0x7ff0 2147483632 r100x7f7d 2138898432 r110xa1b08 662280 ap 0x7fffe1c4 2147475908 fp 0x7fffe1b0 2147475888 sp 0x7fffe110 2147475728 pc 0x92cdb0 9620912 ps 0x3c062914560
[Bug target/58442] bootstrapping vax crashes on NetBSD
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 be helpful I hope.
