On Wed, 2024-01-17 at 17:38 +0800, chenglulu wrote: > > 在 2024/1/13 下午9:05, Xi Ruoyao 写道: > > 在 2024-01-13星期六的 15:01 +0800,chenglulu写道: > > > 在 2024/1/12 下午7:42, Xi Ruoyao 写道: > > > > 在 2024-01-12星期五的 09:46 +0800,chenglulu写道: > > > > > > > > > > I found an issue bootstrapping GCC with -mcmodel=extreme in > > > > > > BOOT_CFLAGS: > > > > > > we need a target hook to tell the generic code > > > > > > UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or > > > > > > we'll > > > > > > see millions lines of messages like > > > > > > > > > > > > ../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC > > > > > > UNSPEC_LA_PCREL_64_PART1 (42) found in variable location > > > > > I build GCC with -mcmodel=extreme in BOOT_CFLAGS, but I haven't > > > > > reproduced the problem you mentioned. > > > > > > > > > > $ ../configure --host=loongarch64-linux-gnu > > > > > --target=loongarch64-linux-gnu --build=loongarch64-linux-gnu \ > > > > > --with-arch=loongarch64 --with-abi=lp64d --enable-tls > > > > > --enable-languages=c,c++,fortran,lto --enable-plugin \ > > > > > --disable-multilib --disable-host-shared --enable-bootstrap > > > > > --enable-checking=release > > > > > $ make BOOT_FLAGS="-mcmodel=extreme" > > > > > > > > > > What did I do wrong?:-( > > > > BOOT_CFLAGS, not BOOT_FLAGS :). > > > > > > > This is so strange. My compilation here stopped due to syntax problems, > > > > > > and I still haven't reproduced the information you mentioned about > > > UNSPEC_LA_PCREL_64_PART1. > > I used: > > > > ../gcc/configure --with-system-zlib --disable-fixincludes \ > > --enable-default-ssp --enable-default-pie \ > > --disable-werror --disable-multilib \ > > --prefix=/home/xry111/gcc-dev > > > > and then > > > > make STAGE1_{C,CXX}FLAGS="-O2 -g" -j8 \ > > BOOT_{C,CXX}FLAGS="-O2 -g -mcmodel=extreme" &| tee gcc-build.log > > > > I guess "-g" is needed to reproduce the issue as well as the messages > > were produced in dwarf generation. > > > I have reproduced this problem, and it can be solved by adding a hook. > > But unfortunately, when using '-mcmodel=extreme -mexplicit-relocs=always' > > to test spec2006 403.gcc, an error will occur. Others have not been > tested yet. > > I roughly debugged it, and the problem should be this: > > The problem is that the address of the instruction ‘ldx.d $r12, $r25, > $r6’ is wrong. > > Wrong assembly: > > 5826 pcalau12i $r13,%got_pc_hi20(recog_data) > 5827 addi.d $r12,$r0,%got_pc_lo12(recog_data) > 5828 lu32i.d $r12,%got64_pc_lo20(recog_data) > 5829 lu52i.d $r12,$r12,%got64_pc_hi12(recog_data) > 5830 ldx.d $r12,$r13,$r12 > 5831 ld.b $r8,$r12,997 > 5832 .loc 1 829 18 discriminator 1 view .LVU1527 > 5833 ble $r8,$r0,.L476 > 5834 ld.d $r6,$r3,16 > 5835 ld.d $r9,$r3,88 > 5836 .LBB189 = . > 5837 .loc 1 839 24 view .LVU1528 > 5838 alsl.d $r7,$r19,$r19,2 > 5839 ldx.d $r12,$r25,$r6 > 5840 addi.d $r17,$r3,120 > 5841 .LBE189 = . > 5842 .loc 1 829 18 discriminator 1 view .LVU1529 > 5843 or $r13,$r0,$r0 > 5844 addi.d $r4,$r12,992 > > Assembly that works fine using macros: > > 3040 la.global $r12,$r13,recog_data > 3041 ld.b $r9,$r12,997 > 3042 ble $r9,$r0,.L475 > 3043 alsl.d $r5,$r16,$r16,2 > 3044 la.global $r15,$r17,recog_data > 3045 addi.d $r4,$r12,992 > 3046 addi.d $r18,$r3,48 > 3047 or $r13,$r0,$r0 > > Comparing the assembly, we can see that lines 5844 and 3045 have the > same function, > > but there is a problem with the base address register optimization at > line 5844. > > regrename.c.283r.loop2_init: > > (insn 6 497 2741 34 (set (reg:DI 180 [ ivtmp.713D.15724 ]) > (const_int 0 [0])) "regrename.c":829:18 discrim 1 156 > {*movdi_64bit} > (nil)) > (insn 2741 6 2744 34 (parallel [ > (set (reg:DI 1502) > (unspec:DI [ > (symbol_ref:DI ("recog_data") [flags 0xc0] > <var_decl 0x7f8c5ffd66c0 recog_data>) > ] UNSPEC_LA_PCREL_64_PART1)) > (set (reg/f:DI 1479) > (unspec:DI [ > (symbol_ref:DI ("recog_data") [flags 0xc0] > <var_decl 0x7f8c5ffd66c0 recog_data>) > ] UNSPEC_LA_PCREL_64_PART2)) > ]) -1 > (expr_list:REG_UNUSED (reg/f:DI 1479) > (nil))) > (insn 2744 2741 2745 34 (set (reg/f:DI 1503) > (mem:DI (plus:DI (reg/f:DI 1479) > (reg:DI 1502)) [0 S8 A8])) 156 {*movdi_64bit} > (expr_list:REG_EQUAL (symbol_ref:DI ("recog_data") [flags 0xc0] > <var_decl 0x7f8c5ffd66c0 recog_data>) > (nil))) > > > Virtual register 1479 will be used in insn 2744, but register 1479 was > assigned the REG_UNUSED attribute in the previous instruction. > > The attached file is the wrong file. > The compilation command is as follows: > > $ ./gcc/cc1 -fpreprocessed regrename.i -quiet -dp -dumpbase regrename.c > -dumpbase-ext .c -mno-relax -mabi=lp64d -march=loongarch64 -mfpu=64 > -msimd=lasx -mcmodel=extreme -mtune=loongarch64 -g3 -O2 > -Wno-int-conversion -Wno-implicit-int -Wno-implicit-function-declaration > -Wno-incompatible-pointer-types -version -o regrename.s > -mexplicit-relocs=always -fdump-rtl-all-all
I've seen some "guality" test failures in GCC test suite as well. Normally I just ignore the guality failures but this time they look very suspicious. I'll investigate these issues... -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University