[Bug d/109231] New: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[Bug d/109231] New: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

            Bug ID: 109231
           Summary: [13 regression] Comparison failure in
                    libphobos/libdruntime/rt/util/typeinfo.o
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
              Host: sparc-sun-solaris2.11
            Target: sparc-sun-solaris2.11
             Build: sparc-sun-solaris2.11

Between 20230317 (2bb71424636fba7944b36b1689e9df22a53f1a3f) and 20230320
(fbd50e867e6a782c7b56c9727bf7e1e74dae4b94),
Solaris/SPARC bootstrap broke with a comparison failure:

Comparing stages 2 and 3
Bootstrap comparison failure!
sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o differs
sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o differs
make[2]: *** [Makefile:32772: compare] Error 1

For some reason, this only happens when using gas, not with the native as.

elfcmp shows

*** section:
[244].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi()
<     0x40:<sym>+0x40:     83 aa 4a a8  fcmpes    %fcc1, %f9, %f8
>     0x40:<sym>+0x40:     81 aa 4a a8  fcmpes    %fcc0, %f9, %f8

*** section:
[245].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi()
<     0x34:<sym>+0x34:     81 aa 0a 48  fcmpd     %fcc0, %d8, %d8
>     0x34:<sym>+0x34:     83 aa 0a 48  fcmpd     %fcc1, %d8, %d8

*** section:
[246].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi()
<     0x3c:<sym>+0x3c:     87 aa 0a 28  fcmps     %fcc3, %f8, %f8
>     0x3c:<sym>+0x3c:     81 aa 0a 28  fcmps     %fcc0, %f8, %f8

*** section:
[247].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi()
<     0x3c:<sym>+0x3c:     83 aa 0a 48  fcmpd     %fcc1, %d8, %d8
>     0x3c:<sym>+0x3c:     85 aa 0a 48  fcmpd     %fcc2, %d8, %d8

*** section:
[248].text._D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi()
<     0x8:<sym>+0x8:       87 aa 0a 28  fcmps     %fcc3, %f8, %f8
>     0x8:<sym>+0x8:       81 aa 0a 28  fcmps     %fcc0, %f8, %f8

*** section:
[249].text._D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi()
<     0x8:<sym>+0x8:       85 aa 0a 48  fcmpd     %fcc2, %d8, %d8
>     0x8:<sym>+0x8:       87 aa 0a 48  fcmpd     %fcc3, %d8, %d8

*** section:
[250].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi()
<     0x8:<sym>+0x8:       83 aa 0a 28  fcmps     %fcc1, %f8, %f8
>     0x8:<sym>+0x8:       85 aa 0a 28  fcmps     %fcc2, %f8, %f8

*** section:
[251].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi:
data information differs
--- <sym>:
_D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi()
<     0x8:<sym>+0x8:       87 aa 0a 48  fcmpd     %fcc3, %d8, %d8
>     0x8:<sym>+0x8:       81 aa 0a 48  fcmpd     %fcc0, %d8, %d8

*** section:
[284].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb:
data information differs
--- <sym>:
_D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb()
<     0x44:<sym>+0x44:     85 aa 4a 28  fcmps     %fcc2, %f9, %f8
>     0x44:<sym>+0x44:     87 aa 4a 28  fcmps     %fcc3, %f9, %f8

*** section:
[287].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb:
data information differs
--- <sym>:
_D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb()
<     0x44:<sym>+0x44:     81 aa 8a 48  fcmpd     %fcc0, %d10, %d8
>     0x44:<sym>+0x44:     83 aa 8a 48  fcmpd     %fcc1, %d10, %d8

*** section:
[295].text._D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf: data
information differs
--- <sym>: _D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf()
<     0x28:<sym>+0x28:     83 aa 0a 20  fcmps     %fcc1, %f8, %f0
>     0x28:<sym>+0x28:     85 aa 0a 20  fcmps     %fcc2, %f8, %f0

*** section:
[302].text._D4core8internal4hash__T13coalesceFloatTdZQsFNaNbNiNfxdZd: data
information differs
--- <sym>: _D4core8internal4hash__T13coalesceFloatTdZQsFNaNbNiNfxdZd()
<     0x20:<sym>+0x20:     87 aa 0a 40  fcmpd     %fcc3, %d8, %d0
>     0x20:<sym>+0x20:     81 aa 0a 40  fcmpd     %fcc0, %d8, %d0

*** section:
[415].text._D4core8internal5array8equality__T7isEqualTfTfZQnFNaNbNiMxPfMxQekZb:
data information differs
--- <sym>:
_D4core8internal5array8equality__T7isEqualTfTfZQnFNaNbNiMxPfMxQekZb()
<     0x2c:<sym>+0x2c:     83 aa 4a 28  fcmps     %fcc1, %f9, %f8
>     0x2c:<sym>+0x2c:     85 aa 4a 28  fcmps     %fcc2, %f9, %f8

*** section:
[420].text._D4core8internal5array8equality__T7isEqualTdTdZQnFNaNbNiMxPdMxQekZb:
data information differs
--- <sym>:
_D4core8internal5array8equality__T7isEqualTdTdZQnFNaNbNiMxPdMxQekZb()
<     0x2c:<sym>+0x2c:     85 aa 8a 48  fcmpd     %fcc2, %d10, %d8
>     0x2c:<sym>+0x2c:     87 aa 8a 48  fcmpd     %fcc3, %d10, %d8

Those differences in register allocation may well not be a gdc problem at all.
Considering the commits in that range, this one

commit 57688950b9328cbb4a9c21eb3199f9132b5119d3
Author: Vladimir N. Makarov <vmakarov@redhat.com>
Date:   Fri Mar 17 08:58:58 2023 -0400

    LRA: Implement combining secondary memory reload and original insn

might be a candidate.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is that with -g vs. non--g?
Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Is that with -g vs. non--g?
> Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn.

No, it's just -fno-checking in stage 2 vs -fchecking=1 in stage 3, no
other changes.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can you find out the gdc and d21 invocation lines for those 2 cases?
I've tried to test it using a cross-compiler:
/usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d
-quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2
-Wall -version -fchecking=1 -fversion=Shared -frelease -ffunction-sections
-fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-fPIC -fversion=Shared -iprefix
/home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem
/home/jakub/src/gcc/obj62/./gcc/include -isystem
/home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime
-I . -v -o /tmp/typeinfo.s1
/usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d
-quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2
-Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections
-fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-fPIC -fversion=Shared -iprefix
/home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem
/home/jakub/src/gcc/obj62/./gcc/include -isystem
/home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime
-I . -v -o /tmp/typeinfo.s2
/usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d
-quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -O2 -Wall
-version -fno-checking -fversion=Shared -frelease -ffunction-sections
-fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-fPIC -fversion=Shared -iprefix
/home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem
/home/jakub/src/gcc/obj62/./gcc/include -isystem
/home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime
-I . -v -o /tmp/typeinfo.s3
but don't see assembly differences in any of that.  objs4/gcc/d21 is
../configure --target sparc-sun-solaris2.12 (but I'm playing with stuff in
x86_64-linux libdruntime tree because I have no idea what all d21 needs...).

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
"jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
>
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Can you find out the gdc and d21 invocation lines for those 2 cases?

sure (with -v -save-temps added):

* stage 2, -fno-checking:

/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc
-B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -fno-checking -fversion=Shared -Wall
-frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000
-fpreview=fieldwise -fpreview=dtorfields -nostdinc -I
/vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -v
-save-temps  -fPIC -fversion=Shared -o rt/util/.libs/typeinfo.o

/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet
-dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2
-Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections
-fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-fPIC -fversion=Shared -iprefix
/var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/
-isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem
/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -I
/vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o
rt/util/.libs/typeinfo.s

* stage 3, -fchecking=1

/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc
-B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -fchecking=1 -fversion=Shared -Wall
-frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000
-fpreview=fieldwise -fpreview=dtorfields -nostdinc -I
/vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d  -fPIC
-fversion=Shared -o rt/util/typeinfo.o -v -save-temps

/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21
/vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet
-dumpdir rt/util/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2 -Wall
-version -fchecking=1 -fversion=Shared -frelease -ffunction-sections
-fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-fPIC -fversion=Shared -iprefix
/var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/
-isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem
/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -I
/vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o rt/util/typeinfo.

> I've tried to test it using a cross-compiler:

It might be that this is hard to reproduce in a cross: as I mentioned,
the failure only happens with gas natively and I'm uncertain if the
configure tests distinguishing those two all work properly in a cross.

FWIW, I'm currently running a reghunt to identify the culprit.  However,
a single step takes 1h25...

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #4)
> It might be that this is hard to reproduce in a cross: as I mentioned,
> the failure only happens with gas natively and I'm uncertain if the
> configure tests distinguishing those two all work properly in a cross.

Could you then also attach auto-host.h ?

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 54720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54720&action=edit
sparc-sun-solaris2.11 auto-host.h

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No luck reproducing this using a cross.

So, could you please attach -fdump-tree-optimized -da dumps from both runs?
Also, check if you are using the same d21 binary, another possibility might be
miscompiled d21.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> No luck reproducing this using a cross.

Ok, so I'll continue with the reghunt.

> So, could you please attach -fdump-tree-optimized -da dumps from both runs?

Sure.  Even compressed with xz, the tarballs are too large for bugzilla,
so I've placed them at

        https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s2.tar.xz
        https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s3.tar.xz

> Also, check if you are using the same d21 binary, another possibility might be
> miscompiled d21.

Both the dumps and the objects/assembler output were created with the
same d21 binary, just the -fno-checking/-fchecking=1 difference.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> No luck reproducing this using a cross.
>
> Ok, so I'll continue with the reghunt.

It's finished now and identified your patch

commit 24c06560a7fa39049911eeb8777325d112e0deb9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 17 18:59:56 2023 +0100

    tree-inline: Fix up multiversioning with vector arguments [PR105554]

as the culprit.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
> Sure.  Even compressed with xz, the tarballs are too large for bugzilla,
> so I've placed them at
> 
> 	https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s2.tar.xz
> 	https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s3.tar.xz
> 
> > Also, check if you are using the same d21 binary, another possibility might be
> > miscompiled d21.
> 
> Both the dumps and the objects/assembler output were created with the
> same d21 binary, just the -fno-checking/-fchecking=1 difference.

But the typeinfo.s is the same in both tarballs, optimized dump too, and while
some
RTL dumps differ slightly in used addresses, I see no code changes in those
either.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #9)
> > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> > Uni-Bielefeld.DE> ---
> >> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> >> No luck reproducing this using a cross.
> >
> > Ok, so I'll continue with the reghunt.
> 
> It's finished now and identified your patch
> 
> commit 24c06560a7fa39049911eeb8777325d112e0deb9
> Author: Jakub Jelinek <jakub@redhat.com>
> Date:   Fri Mar 17 18:59:56 2023 +0100
> 
>     tree-inline: Fix up multiversioning with vector arguments [PR105554]
> 
> as the culprit.

That is just weird.  Looking at the cross case, I see tree_function_versioning
being called 5 times, but in all cases DECL_FUNCTION_SPECIFIC_TARGET and
DECL_FUNCTION_SPECIFIC_OPTIMIZATION of both old_decl and new_decl are NULL,
4 times from that from cgraph_node::create_version_clone_with_body with NULL
target_attributes.  So I don't much see how it could make a difference.
So, do you really see changes with that commit, if so, are they in the
-fno-checking or -fchecking=1 case (r13-6738 vs. r13-6739), do any changes
appear in -fdump-tree-optimized, or if not, where things differ first with
-fdump-noaddr -fdump-rtl-all?

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, I have also backported the r13-6739 commit to 12 branch in r12-9293, does
that branch fail to bootstrap too?

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I found I could perhaps use gcc211 on CompilerFarm to try to reproduce it,
currently building GCC 11 for working GDC there.
What exact configure should I use for the trunk gcc?
For gcc 11 I'm trying
../configure --prefix=/export/home/jakub/gcc-11-inst --enable-languages=c,c++,d
--disable-libssp --disable-nls --enable-threads=posix --with-gmp=/opt/csw
--with-included-gettext --with-ld=/opt/csw/bin/gld --with-gnu-ld
--with-as=/opt/csw/bin/gas --with-gnu-as --with-libiconv-prefix=/opt/csw
--with-mpfr=/opt/csw --with-system-zlib=/opt/csw --enable-libphobos
--disable-bootstrap

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I found I could perhaps use gcc211 on CompilerFarm to try to reproduce it,
> currently building GCC 11 for working GDC there.

Right, although on Solaris/SPARC GCC 9.3.0 works for me, too.

> What exact configure should I use for the trunk gcc?

During the reghunt, I used (albeit on Solaris 11.4)

configure --without-ppl --without-cloog --enable-languages=d --disable-lto
--disable-libatomic --disable-libcc1 --disable-libquadmath --disable-libssp
--disable-libitm --disable-libvtv --disable-libsanitizer --disable-libgomp
--with-ld=/usr/bin/ld --without-gnu-ld --with-as=/vol/gcc/bin/gas-2.40
--with-gnu-as --disable-multilib

All the --disable-* options serve to speed up the build, including
--disable-multilib.

I'd strongly recommend using /bin/ld; that's what I've been using all
the time.

> For gcc 11 I'm trying
> ../configure --prefix=/export/home/jakub/gcc-11-inst --enable-languages=c,c++,d
> --disable-libssp --disable-nls --enable-threads=posix --with-gmp=/opt/csw
> --with-included-gettext --with-ld=/opt/csw/bin/gld --with-gnu-ld
> --with-as=/opt/csw/bin/gas --with-gnu-as --with-libiconv-prefix=/opt/csw
> --with-mpfr=/opt/csw --with-system-zlib=/opt/csw --enable-libphobos
> --disable-bootstrap

I don't think you need the explicit --enable-threads=posix
--with-included-gettext; likewise I didn't have any need for
--with-system-zlib=/opt/csw or similar.

I've been working with a self-compiled gas 2.40; I'm uncertain if the
/opt/csw one is ok, but guess so.

You'll certainly need gmp/mpfr/mpc from /opt/csw; at least for one of
the three the bundled version is too old on 11.3.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, after installing gcc 11 I've tried
PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ ../configure
--prefix=/export/home/jakub/gcc-inst --enable-languages=c,c++,d
--disable-libssp --disable-libsanitizer --disable-nls --with-gmp=/opt/csw
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/opt/csw/bin/gas
--with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw
--enable-libphobos --disable-multilib --enable-obsolete
PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ gmake -j16 > LOG 2>&1
but that failed miserably during stage1:
g++ -std=c++11 -no-pie   -g -DIN_GCC     -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -static-libstdc++
-static-libgcc  -o lto1 lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o
lto/lto-partition.o lto/lto-symtab.o lto/lto-common.o libbackend.a main.o
libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a -lisl -L/opt/csw/lib -L/opt/csw/lib -lmpc -lmpfr
-lgmp   -L./../zlib -lz  libcommon.a ../libcpp/libcpp.a 
/opt/csw/lib/libiconv.so -R/opt/csw/lib ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
Undefined                       first referenced
 symbol                             in file
_ZSt28__throw_bad_array_new_lengthv libbackend.a(auto-profile.o)
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[3]: *** [../../gcc/lto/Make-lang.in:96: lto1] Error 1
Strangely, /export/home/jakub/gcc-11-inst/lib/gcc/sparc*/11*/ directory only
contains *.a libraries and no *.so symlinks, I've linked there ../../../lib*.so
but it still fails with that.  Is that because the various --with-*=/opt/csw
options added
-L/opt/csw/lib and that directory contains the oldish libstdc++.a?
Do I need to use CC='gcc -L/export/home/jakub/gcc-11-inst/lib
-R/export/home/jakub/gcc-11-inst/lib/' CXX='g++
-L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/' as
workaround?

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Used
PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ CC='gcc
-L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
CXX='g++ -L/export/home/jakub/gcc-11-inst/lib
-R/export/home/jakub/gcc-11-inst/lib/' GDC='gdc
-L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
../configure --prefix=/export/home/jakub/gcc-inst --enable-languages=c,c++,d
--disable-libssp --disable-libsanitizer --disable-nls --with-gmp=/opt/csw
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/opt/csw/bin/gas
--with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw
--enable-libphobos --disable-multilib --enable-obsolete
in the end, which worked, but unfortunately I can't reproduce, gobjdump -dr
on
{prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o
and
{prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o
is identical.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> BTW, I have also backported the r13-6739 commit to 12 branch in r12-9293, does
> that branch fail to bootstrap too?

I usually try the gcc-12 branch only once a week.  So I ran a bootstrap
there last night: worked without issues.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> So, after installing gcc 11 I've tried
[...]
> Undefined                       first referenced
>  symbol                             in file
> _ZSt28__throw_bad_array_new_lengthv libbackend.a(auto-profile.o)
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[3]: *** [../../gcc/lto/Make-lang.in:96: lto1] Error 1
> Strangely, /export/home/jakub/gcc-11-inst/lib/gcc/sparc*/11*/ directory only
> contains *.a libraries and no *.so symlinks, I've linked there ../../../lib*.so
> but it still fails with that.  Is that because the various --with-*=/opt/csw
> options added

Those only exist in $prefix/lib.

> -L/opt/csw/lib and that directory contains the oldish libstdc++.a?

When I tried building on gcc211 a long time ago, I had so many problems
with the stuff in /opt/csw that I completely ignored it.  I can't help
but feel that many issues with that system are admin-made and
unnecessary.

> Do I need to use CC='gcc -L/export/home/jakub/gcc-11-inst/lib
> -R/export/home/jakub/gcc-11-inst/lib/' CXX='g++
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/' as
> workaround?

Instead, I've build my own copies of gmp/mpfr/mpc in ~ro/gcc with ABI=32
--disable-shared to avoid RPATH issues.

I had no need for special -L/-R switches this way.  The 2020 build tree
is still in ~ro/gcc/obj/master.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Used
> PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
> LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ CC='gcc
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
> CXX='g++ -L/export/home/jakub/gcc-11-inst/lib
> -R/export/home/jakub/gcc-11-inst/lib/' GDC='gdc
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
> ../configure --prefix=/export/home/jakub/gcc-inst --enable-languages=c,c++,d
> --disable-libssp --disable-libsanitizer --disable-nls --with-gmp=/opt/csw
> --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/opt/csw/bin/gas
> --with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw
> --enable-libphobos --disable-multilib --enable-obsolete
> in the end, which worked, but unfortunately I can't reproduce, gobjdump -dr
> on
> {prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o
> and
> {prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o
> is identical.

I haven't yet been able to reproduce the comparison failure: while last
night's trunk bootstrap with gas failed again with the typeinfo.o
comparison failure, when I try to rerun

make GDCFLAGS='-g -O2 -save-temps -fdump-tree-optimized -da'
rt/util/typeinfo.lo

in the stage 2 and stage 3 sparc-sun-solaris2.11/libphobos/libdruntime
(each time with all the stage<n> directories restored to their
unprefixed names at the toplevel), I didn't get that difference.

Very weird: might be some memory corruption issue somewhere, influenced
by the exact environment variables used during the build e.g.  I have no
idea how to actually trace this down, though.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Tried valgrind on the cross d21 on x86_64 and didn't see anything.
Perhaps modify the makefiles such that it uses -fdump-tree-all -da already when
compiling typeinfo.lo?

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
> Perhaps modify the makefiles such that it uses -fdump-tree-all -da already when
> compiling typeinfo.lo?

I'll give that a whirl.  However, my SPARC box is pretty busy right now
with the weekly bootstraps, so this will be later this weekend only.

In the meantime, I try to reproduce the issue on gcc211.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> Tried valgrind on the cross d21 on x86_64 and didn't see anything.
>> Perhaps modify the makefiles such that it uses -fdump-tree-all -da already when
>> compiling typeinfo.lo?
>
> I'll give that a whirl.  However, my SPARC box is pretty busy right now
> with the weekly bootstraps, so this will be later this weekend only.

Bootstrapping with

        GDCFLAGS_FOR_TARGET='-O2 -g -fdump-tree-optimized -da'

didn't show the comparison failure.

> In the meantime, I try to reproduce the issue on gcc211.

That didn't show the failure either.

To make things even more weird, I've run several regular bootstraps
since:

* Friday night:

** Solaris 11.4 trunk (latest development build, bare metal, SPARC-S7):
  32-bit gas/ld and 32-bit gas/gld bootstraps failed with the comparison
  failure, while 64-bit gas/ld completed.

** Solaris 11.4 (latest update, kernel zone/VM, different host,
   SPARC-T5): 32-bit gas/ld failed.

** Solaris 11.3 (latest update, kernel zone/VM, SPARC-S7): 32-bit gas/ld
   failed.

* Monday night: 32-bit gas/ld bootstrap passed.

* Tuesday night: 32-bit gas/ld bootstrap failed again.

Seems incredibly fragile, unfortunately.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh, that sounds like an uninitialized use of something somewhere,
unfortunately if it is really my commit, I don't understand how it could cause
it.
All it changes is that when tree_versioning is called, the push_struct_function
-> allocate_struct_function will not do the
      if (!abstract_p)
        {
          /* Now that we have activated any function-specific attributes
             that might affect layout, particularly vector modes, relayout
             each of the parameters and the result.  */
          relayout_decl (result);
          for (tree parm = DECL_ARGUMENTS (fndecl); parm;
               parm = DECL_CHAIN (parm))
            relayout_decl (parm);
        }
and
      if (!abstract_p && aggregate_value_p (result, fndecl))
        {
#ifdef PCC_STATIC_STRUCT_RETURN
          cfun->returns_pcc_struct = 1;
#endif
          cfun->returns_struct = 1;
        }
parts it did before when abstract_p was false in this case.
As I wrote, initialize_cfun has
  cfun->returns_struct = src_cfun->returns_struct;
  cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
a few lines later, so whatever it sets cfun->returns* to should be overritten
quickly.
It is true allocate_stack_function calls before that allocate_stack_usage_info
and
stdarg_p but neither of those two should care about those flag or whatever
relayout_decl does.
Perhaps try to undo my patch in a different way, like
--- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
+++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
@@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
   gimple_register_cfg_hooks ();

   /* Get clean struct function.  */
-  push_struct_function (new_fndecl, true);
+  push_struct_function (new_fndecl, false);
   targetm.target_option.relayout_function (new_fndecl);

   /* We will rebuild these, so just sanity check that they are empty.  */
or
--- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
+++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
@@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c

   /* Get clean struct function.  */
   push_struct_function (new_fndecl, true);
+  relayout_decl (DECL_RESULT (new_fndecl));
+  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
+    relayout_decl (parm);
   targetm.target_option.relayout_function (new_fndecl);
+  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);

   /* We will rebuild these, so just sanity check that they are empty.  */
   gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
and see if that changes anything?  Of course both of those patches break the
PR105554
again.  Or if the latter helps, try to comment out the different parts of it
too.

Seems there was some valgrind for SPARC Solaris out of tree, but can't find it
anymore...

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
[...]
> Perhaps try to undo my patch in a different way, like
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
>    gimple_register_cfg_hooks ();
>
>    /* Get clean struct function.  */
> -  push_struct_function (new_fndecl, true);
> +  push_struct_function (new_fndecl, false);
>    targetm.target_option.relayout_function (new_fndecl);
>
>    /* We will rebuild these, so just sanity check that they are empty.  */
> or
> --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
>
>    /* Get clean struct function.  */
>    push_struct_function (new_fndecl, true);
> +  relayout_decl (DECL_RESULT (new_fndecl));
> +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> (parm))
> +    relayout_decl (parm);
>    targetm.target_option.relayout_function (new_fndecl);
> +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
>
>    /* We will rebuild these, so just sanity check that they are empty.  */
>    gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> and see if that changes anything?  Of course both of those patches break the
> PR105554
> again.  Or if the latter helps, try to comment out the different parts of it
> too.

So far, I've tried both variants and in each case, the comparison
failure is gone.

> Seems there was some valgrind for SPARC Solaris out of tree, but can't find it
> anymore...

There was one back in the 2014-2017 timeframe, but the sources lived on
bitbucket and are gone, apparently.  The author (Ivo Raisr) since left
Oracle and works for RedHat/Prague AFAICT.  However, reviving that port
even if the sources were available would be a major feat.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #24)
> > --- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> [...]
> > Perhaps try to undo my patch in a different way, like
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:47:21.546947442 +0200
> > @@ -2785,7 +2785,7 @@ initialize_cfun (tree new_fndecl, tree c
> >    gimple_register_cfg_hooks ();
> >
> >    /* Get clean struct function.  */
> > -  push_struct_function (new_fndecl, true);
> > +  push_struct_function (new_fndecl, false);
> >    targetm.target_option.relayout_function (new_fndecl);
> >
> >    /* We will rebuild these, so just sanity check that they are empty.  */
> > or
> > --- gcc/tree-inline.cc  2023-03-17 18:59:50.226199917 +0100
> > +++ gcc/tree-inline.cc  2023-03-29 12:49:16.580255668 +0200
> > @@ -2786,7 +2786,11 @@ initialize_cfun (tree new_fndecl, tree c
> >
> >    /* Get clean struct function.  */
> >    push_struct_function (new_fndecl, true);
> > +  relayout_decl (DECL_RESULT (new_fndecl));
> > +  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> > (parm))
> > +    relayout_decl (parm);
> >    targetm.target_option.relayout_function (new_fndecl);
> > +  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> >
> >    /* We will rebuild these, so just sanity check that they are empty.  */
> >    gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> > and see if that changes anything?  Of course both of those patches break the
> > PR105554
> > again.  Or if the latter helps, try to comment out the different parts of it
> > too.
> 
> So far, I've tried both variants and in each case, the comparison
> failure is gone.

Given that the reproducers weren't reliable, I'm afraid it would take at least
2-3
runs to get something that says something.
Anyway, as I said for the second version, it would be nice to also try
subvariants:
//  relayout_decl (DECL_RESULT (new_fndecl));
  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN (parm))
    relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//    relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
//  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
and
//  relayout_decl (DECL_RESULT (new_fndecl));
//  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
(parm))
//    relayout_decl (parm);
  targetm.target_option.relayout_function (new_fndecl);
  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
so see if the comparison failure is fixed by the result relayout, or by
argument
relayout or by the aggregate_value_p call actually having some side-effects
other than return value.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #24)
>> > --- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> [...]
>> So far, I've tried both variants and in each case, the comparison
>> failure is gone.
>
> Given that the reproducers weren't reliable, I'm afraid it would take at least
> 2-3
> runs to get something that says something.

indeed, even though so far following the exact same procedure has always
failed (or succeeded) in the same way.

> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
[...]
> so see if the comparison failure is fixed by the result relayout, or by
> argument
> relayout or by the aggregate_value_p call actually having some side-effects
> other than return value.

I certainly plan to do so once the machine is idle again, probably tomorrow.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Thanks.  It is a mystery so far :(.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
> //  relayout_decl (DECL_RESULT (new_fndecl));
>   for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN (parm))
>     relayout_decl (parm);
>   targetm.target_option.relayout_function (new_fndecl);
> //  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> and
>   relayout_decl (DECL_RESULT (new_fndecl));
> //  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> (parm))
> //    relayout_decl (parm);
>   targetm.target_option.relayout_function (new_fndecl);
> //  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> and
> //  relayout_decl (DECL_RESULT (new_fndecl));
> //  for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN
> (parm))
> //    relayout_decl (parm);
>   targetm.target_option.relayout_function (new_fndecl);
>   aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);
> so see if the comparison failure is fixed by the result relayout, or by
> argument
> relayout or by the aggregate_value_p call actually having some side-effects
> other than return value.

Of those three subvariants, only the third one passed the build without
the comparison failure.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So aggregate_value_p has some side-effects other than return value then?  Ugh.
Anyway, my patch intention has been to avoid the relayouts.
So, just calling aggregate_value_p there or perhaps instead later when we
finalize
DECL_RESULT and the like is an option, just would like to understand what
side-effects it has.  Will step through on the cross-compiler.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, if I add the
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2787,6 +2787,7 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
profile_count count)
   /* Get clean struct function.  */
   push_struct_function (new_fndecl, true);
   targetm.target_option.relayout_function (new_fndecl);
+  aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl);

   /* We will rebuild these, so just sanity check that they are empty.  */
   gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
I see 5 calls of this in this spot, two with int return type, one with TFmode
floating one, one with uint and one with bool.
aggregate_value_p calls targetm.calls.return_in_memory but I don't see
sparc_return_in_memory to have any side-effects other than return value.
Next it calls reg = hard_function_value (type, 0, fntype, 0); which does
allocate a REG rtx, but doesn't save it anywhere.  It then calls fntype_abi and
hard_regno_nregs
and predefined_function_abi::clobbers_full_reg_p, but I don't see any
side-effects in those either.
Nothing seems to cache its results in any way.

Confused...

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If the important side-effect is allocation of some GC memory, then perhaps
(assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float,
uint and bool) testing hack might be:
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
profile_count count)
   /* Get clean struct function.  */
   push_struct_function (new_fndecl, true);
   targetm.target_option.relayout_function (new_fndecl);
+  if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl))))
+    gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8);

   /* We will rebuild these, so just sanity check that they are empty.  */
   gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
If that would help, then it is just bad luck and bug somewhere else than here.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If the important side-effect is allocation of some GC memory, then perhaps
> (assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float,
> uint and bool) testing hack might be:

I haven't verified this yet.

> --- a/gcc/tree-inline.cc
> +++ b/gcc/tree-inline.cc
> @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
> profile_count count)
>    /* Get clean struct function.  */
>    push_struct_function (new_fndecl, true);
>    targetm.target_option.relayout_function (new_fndecl);
> +  if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl))))
> +    gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8);
>
>    /* We will rebuild these, so just sanity check that they are empty.  */
>    gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);

This doesn't compile as is:

In file included from /var/gcc/reghunt/master/gcc/tree-inline.cc:26:
/var/gcc/reghunt/master/gcc/tree-inline.cc: In function ‘void
initialize_cfun(tree, tree, profile_count)’:
/var/gcc/reghunt/master/gcc/rtl.h:728:54: error: base operand of ‘->’ is not a
pointer
  728 | #define GET_MODE(RTX)           ((machine_mode) (RTX)->mode)
      |                                                      ^~
/var/gcc/reghunt/master/gcc/tree-inline.cc:2791:18: note: in expansion of macro
‘GET_MODE’
 2791 |     gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8);
      |                  ^~~~~~~~

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oops, sorry.
gen_raw_REG (TYPE_MODE (DECL_RESULT (new_fndecl)), 8);

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Oops, sorry.
> gen_raw_REG (TYPE_MODE (DECL_RESULT (new_fndecl)), 8);

While this compiles, I run into

during IPA pass: inline
In function ‘gcov_topn_add_value.constprop’:
cc1: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (result_decl) in initialize_cfun, at tree-inline.cc:2791
0x1f6fc8f tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
        /var/gcc/reghunt/master/gcc/tree.cc:8931
0xd8af2b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
        /var/gcc/reghunt/master/gcc/tree.h:3663
0x1b601a3 initialize_cfun
        /var/gcc/reghunt/master/gcc/tree-inline.cc:2791
0x1b6df53 tree_function_versioning(tree_node*, tree_node*,
vec<ipa_replace_map*, va_gc, vl_embed>*, ipa_param_adjustments*, bool,
bitmap_head*, basic_block_def*)
        /var/gcc/reghunt/master/gcc/tree-inline.cc:6239
0x115d2d3 cgraph_node::materialize_clone()
        /var/gcc/reghunt/master/gcc/cgraphclones.cc:1156
0x1140993 cgraph_node::get_untransformed_body()
        /var/gcc/reghunt/master/gcc/cgraph.cc:3995
0x15debaf maybe_materialize_called_clones
        /var/gcc/reghunt/master/gcc/ipa-inline-transform.cc:720
0x15def5b inline_transform(cgraph_node*)
        /var/gcc/reghunt/master/gcc/ipa-inline-transform.cc:777
0x189818f execute_one_ipa_transform_pass
        /var/gcc/reghunt/master/gcc/passes.cc:2343
0x1898547 execute_all_ipa_transforms(bool)
        /var/gcc/reghunt/master/gcc/passes.cc:2406
0x115358b cgraph_node::expand()
        /var/gcc/reghunt/master/gcc/cgraphunit.cc:1826
0x115410b expand_all_functions
        /var/gcc/reghunt/master/gcc/cgraphunit.cc:2016
0x115522b symbol_table::compile()
        /var/gcc/reghunt/master/gcc/cgraphunit.cc:2390
0x1155917 symbol_table::finalize_compilation_unit()
        /var/gcc/reghunt/master/gcc/cgraphunit.cc:2575

e.g. building stage 1 libgcc (_gcov_merge_topn).

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sorry for wasting your time.
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
profile_count count)
   /* Get clean struct function.  */
   push_struct_function (new_fndecl, true);
   targetm.target_option.relayout_function (new_fndecl);
+  if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl))))
+    gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8);

   /* We will rebuild these, so just sanity check that they are empty.  */
   gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
or could be
    gen_raw_REG (TYPE_MODE (TREE_TYPE (DECL_RESULT (new_fndecl))), 8);

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #36 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Sorry for wasting your time.

No worries: it's mostly the SPARC box doing the compiles ;-)

> --- a/gcc/tree-inline.cc
> +++ b/gcc/tree-inline.cc
> @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
> profile_count count)
>    /* Get clean struct function.  */
>    push_struct_function (new_fndecl, true);
>    targetm.target_option.relayout_function (new_fndecl);
> +  if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl))))
> +    gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8);
>
>    /* We will rebuild these, so just sanity check that they are empty.  */
>    gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);

This one passed the build.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #36)
> > --- a/gcc/tree-inline.cc
> > +++ b/gcc/tree-inline.cc
> > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
> > profile_count count)
> >    /* Get clean struct function.  */
> >    push_struct_function (new_fndecl, true);
> >    targetm.target_option.relayout_function (new_fndecl);
> > +  if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl))))
> > +    gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8);
> >
> >    /* We will rebuild these, so just sanity check that they are empty.  */
> >    gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL);
> 
> This one passed the build.

That is kind of bad news for trying to debug where the problem is, because the
above
patch has only effect of doing 4 extra GC allocations, so the -fno-checking vs.
-fchecking=1 bug was just latent before, perhaps some code generation decision
is done from pointer comparisons or something similar.

If the problem without this patch is reliably reproduceable even with the same
d21 binary but not after enabling all the dumps, perhaps another attempt would
be try to see
if enabling just one dump somewhere would make it latent again as well or if it
would still reproduce.  So rather than trying to -fdump-tree-all -da, perhaps
just try -fdump-tree-optimized, or -fdump-rtl-vregs or -fdump-rtl-postreload
etc.  If the assemblies differ even with just one of those dumps enabled, you
can see if there is any difference in the dump or not.
Other option would be only side-by-side debugging but without the dumps
actually working it is much harder to find out where to look at.

[Bug d/109231] [13/14 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As nobody but Rainer managed to reproduce this and we don't know what's going
on, postponing for 13.2.

[Bug d/109231] [13/14 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #39 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #38)
> As nobody but Rainer managed to reproduce this and we don't know what's
> going on, postponing for 13.2.

When building the gcc-13 branch for the first time, I forgot to include the
workaround patch for this PR, still the build went just fine without.  Later
on, I disabled the workaround for trunk, too, without ill effect.  I guess
we can close this for now: should the issue ever reappear, I'll reopen.