[Bug ipa/113359] [13 Regression] LTO miscompilation of ceph on aarch64

["jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #9 from Martin Jambor <jamborm at gcc dot gnu.org> ---
SRA creates the replacements (in GCC 13) during total scalarization,
i.e. the bit that is not driven by pre-existing accesses to
aggregates, but because it sees an aggregate that is small and regular
and so it is split according to its type in the hope it will go away.

Unfortunately in the LTO and non-LTO case, they see a different type.
I have added a dumping of types and fields of totally scalarized
records and got the following.

In the non-LTO case, the type of the aggregate is:
  <record_type 0xffff553cabd0 pair readonly sizes-gimplified cxx-odr-p type_1
type_5 type_6 TI
    size <integer_cst 0xffff6fe96090 type <integer_type 0xffff6fe9c0a8
bitsizetype> constant 128>
    unit-size <integer_cst 0xffff6fe960a8 type <integer_type 0xffff6fe9c000
sizetype> constant 16>
    align:64 warn_if_not_align:0 symtab:1430035184 alias-set -1 canonical-type
0xffff553cabd0
    ...

and specifically its third field is a pointer:
  <field_decl 0xffff55161ab0 second
    type <pointer_type 0xffff4cf303f0
        type <record_type 0xffff4cf30348 Context cxx-odr-p type_1 type_4 type_5
type_6 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xffff562720a8 context <translation_unit_decl 0xffff6fe9a000
/home/jakub/rpmbuild/BUILD/ceph-18.2.1/src/common/Timer.cc>
            pointer_to_this <pointer_type 0xffff4cf303f0>>
        unsigned DI
        size <integer_cst 0xffff6fe96048 constant 64>
        unit-size <integer_cst 0xffff6fe96060 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xffff562729d8 reference_to_this <reference_type 0xffff4cf6c738>>
    used unsigned nonlocal decl_3 DI /usr/include/c++/13/bits/stl_pair.h:194:11
    size <integer_cst 0xffff6fe96048 type <integer_type 0xffff6fe9c0a8
bitsizetype> constant 64>
    unit-size <integer_cst 0xffff6fe96060 type <integer_type 0xffff6fe9c000
sizetype> constant 8>
    align:64 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 0
    offset <integer_cst 0xffff6fe96078 type <integer_type 0xffff6fe9c000
sizetype> constant 0>
    bit-offset <integer_cst 0xffff6fe96048 type <integer_type 0xffff6fe9c0a8
bitsizetype> constant 64> context <record_type 0xffff553ba540 pair>>


However, in the LTO case the type of the aggregate is:
  <record_type 0xffff61cc1498 pair cxx-odr-p TI
    size <integer_cst 0xffff623fdd08 type <integer_type 0xffff624100a8
bitsizetype> constant 128>
    unit-size <integer_cst 0xffff623fdd20 type <integer_type 0xffff62410000
sizetype> constant 16>
    align:64 warn_if_not_align:0 symtab:0 alias-set 98 canonical-type
0xffff61cc1498
    ...

which however has an unsigned int as its third field:
 <field_decl 0xffff61cc05f0 second
    type <integer_type 0xffff62410690 unsigned int public unsigned SI
        size <integer_cst 0xffff623fdf00 constant 32>
        unit-size <integer_cst 0xffff623fdf18 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xffff62410690 precision:32 min <integer_cst 0xffff623fdf30 0> max <integer_cst
0xffff623fdee8 4294967295>
        pointer_to_this <pointer_type 0xffff61cf50a8> reference_to_this
<reference_type 0xffff618fd5e8>>
    unsigned nonlocal SI /usr/include/c++/13/bits/stl_pair.h:194:11
    size <integer_cst 0xffff623fdf00 type <integer_type 0xffff624100a8
bitsizetype> constant 32>
    unit-size <integer_cst 0xffff623fdf18 type <integer_type 0xffff62410000
sizetype> constant 4>
    align:32 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 0
    offset <integer_cst 0xffff623fdcf0 type <integer_type 0xffff62410000
sizetype> constant 0>
    bit-offset <integer_cst 0xffff623fdcc0 type <integer_type 0xffff624100a8
bitsizetype> constant 64> context <record_type 0xffff61cc1498 pair>>

An so only an unsigned int replacement is created.

The name of the aggregate indicates it has been created by IPA-SRA and
so that is where I am looking right now, but IPA-SRA simply takes (and
streams) the type of the access in the original function body for
these.  Can't this perhaps be some type-merging issue?