在 2024/1/17 下午5:50, Xi Ruoyao 写道:
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...

I've also seen this type of failed regression tests and I'll continue to look at this issue as well.

Reply via email to