[Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313

[Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313

[asolokha at gmx dot com]

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

            Bug ID: 103147
           Summary: ICE in register_tuple_type, at
                    config/aarch64/aarch64-builtins.c:1313
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gcc-12.0.0-alpha20211107 snapshot (g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6)
ICEs when compiling the following line, found in include/arm_neon.h, w/
-fpack-struct:

% aarch64-linux-gnu-gcc-12.0.0 -fpack-struct -c gn1gzbom.c
gn1gzbom.c:1:9: internal compiler error: in register_tuple_type, at
config/aarch64/aarch64-builtins.c:1313
    1 | #pragma GCC aarch64 "arm_neon.h"
      |         ^~~
0x814570 register_tuple_type
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/config/aarch64/aarch64-builtins.c:1313
0x814570 handle_arm_neon_h()
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/config/aarch64/aarch64-builtins.c:1338
0x9ea621 aarch64_pragma_aarch64
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/config/aarch64/aarch64-c.c:300
0x926f77 c_parser_pragma
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/c/c-parser.c:12596
0x952ad5 c_parser_external_declaration
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/c/c-parser.c:1761
0x9530eb c_parser_translation_unit
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/c/c-parser.c:1653
0x9530eb c_parse_file()
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/c/c-parser.c:23222
0x9b9509 c_common_parse_file()
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/c-family/c-opts.c:1237

Practically every aarch64 target test in the gcc testsuite is affected  by
this.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
   Last reconfirmed|                            |2021-11-09
     Ever confirmed|0                           |1
            Summary|ICE in register_tuple_type, |[12 Regression] ICE in
                   |at                          |register_tuple_type with
                   |config/aarch64/aarch64-buil |include "arm_neon.h" and
                   |tins.c:1313                 |-fpack-struct
             Status|UNCONFIRMED                 |NEW
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, I might look at this once PR 99657 patch is submitted.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jonathan.wright at arm dot com,
                   |                            |wirkus at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, -fpack-struct is an ABI changing option, so it should be used with extra
care.
Anyway, I guess the backends (both aarch64 and arm) need to decide what exactly
they want.
Either for these internal lang_hooks.types.simulate_record_decl created types
temporarily rest to default the -fpack-struct stuff, or allow them to have
smaller alignment, or increase the alignment afterwards.
Because those
  tree t = lang_hooks.types.simulate_record_decl (input_location,
                                                  tuple_type_name,
                                                  make_array_slice (&field,
                                                                    1));
  gcc_assert (TYPE_MODE_RAW (t) == TYPE_MODE (t)
              && TYPE_ALIGN (t) == alignment);
and
  ls64_arm_data_t = lang_hooks.types.simulate_record_decl (input_location,
                         tuple_type_name,
                         make_array_slice (&field, 1));

  gcc_assert (TYPE_MODE (ls64_arm_data_t) == V8DImode);
  gcc_assert (TYPE_MODE_RAW (ls64_arm_data_t) == TYPE_MODE (ls64_arm_data_t));
  gcc_assert (TYPE_ALIGN (ls64_arm_data_t) == 64);
assertions otherwise of course fail.
Now, seems the arm backend actually doesn't assert this.
Note, when those types were defined in arm_neon.h, -fpack-struct usedd to be
applied to those.

The changes were done in r12-4907-g8197ab94b47c814632d758dd36a121ad4114ff70
and r12-5955-gfdcddba8f29ea3878851b8b4cd37d0fd3476d3bf

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Any progress on this?
I can help with it, but I can't decide what solution the backend prefers
(ignore -fpack-struct temporarily for those, or adjust the asserts, something
else).

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think it makes sense to ignore -fpack-struct for the intrinsic API/ABI
defined types.  OTOH using the option in general doesn't make much sense so an

#if __GCC_PACK_STRUCT
#error "do not use -fpack-struct with arm_neon.h"
#endif

in those headers might make sense as well.  Alternatively

#pragma GCC push_options
#pragma GCC optimize("no-pack-struct")
...
#pragma GCC pop_options

around the header contents might work as well.

Maybe the simulate_record_decl should ignore -fpack-struct in general.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org

--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Mine.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:14814e20161d7b6a4e9cac244c7013fa56f71f55

commit r12-8000-g14814e20161d7b6a4e9cac244c7013fa56f71f55
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Apr 5 17:31:35 2022 +0100

    aarch64: Fix -fpack-struct + <arm_neon.h> [PR103147]

    This PR is about -fpack-struct causing a crash when <arm_neon.h>
    is included.  The new register_tuple_type code was expecting a
    normal unpacked structure layout instead of a packed one.

    For SVE we got around this by temporarily suppressing -fpack-struct,
    so that the tuple types always have their normal ABI.  However:

    (a) The SVE ACLE tuple types are defined to be abstract.  The fact
        that GCC uses structures is an internal implementation detail.

    (b) In contrast, the ACLE explicitly defines the Advanced SIMD
        tuple types to be particular structures.

    (c) Clang and previous versions of GCC are consistent in applying
        -fpack-struct to these tuple structures.

    This patch therefore honours -fpack-struct and -fpack-struct=.  It also
    adds tests for some other combinations, such as -mgeneral-regs-only and
    -fpack-struct -mstrict-align.

    gcc/
            PR target/103147
            * config/aarch64/aarch64-protos.h (aarch64_simd_switcher): New
class.
            * config/aarch64/aarch64-sve-builtins.h (sve_switcher): Inherit
            from aarch64_simd_switcher.
            * config/aarch64/aarch64-builtins.cc (aarch64_simd_tuple_modes):
            New variable.
            (aarch64_lookup_simd_builtin_type): Use it instead of TYPE_MODE.
            (register_tuple_type): Add more asserts.  Expect the alignment
            of the structure to be subject to flag_pack_struct and
            maximum_field_alignment.  Set aarch64_simd_tuple_modes.
            (aarch64_simd_switcher::aarch64_simd_switcher): New function.
            (aarch64_simd_switcher::~aarch64_simd_switcher): Likewise.
            (handle_arm_neon_h): Hold an aarch64_simd_switcher throughout.
            (aarch64_general_init_builtins): Hold an aarch64_simd_switcher
            while calling aarch64_init_simd_builtins.
            * config/aarch64/aarch64-sve-builtins.cc
(sve_switcher::sve_switcher)
            (sve_switcher::~sve_switcher): Remove code now performed by
            aarch64_simd_switcher.

    gcc/testsuite/
            PR target/103147
            * gcc.target/aarch64/pr103147-1.c: New test.
            * gcc.target/aarch64/pr103147-2.c: Likewise.
            * gcc.target/aarch64/pr103147-3.c: Likewise.
            * gcc.target/aarch64/pr103147-4.c: Likewise.
            * gcc.target/aarch64/pr103147-5.c: Likewise.
            * gcc.target/aarch64/pr103147-6.c: Likewise.
            * gcc.target/aarch64/pr103147-7.c: Likewise.
            * gcc.target/aarch64/pr103147-8.c: Likewise.
            * gcc.target/aarch64/pr103147-9.c: Likewise.
            * gcc.target/aarch64/pr103147-10.c: Likewise.
            * g++.target/aarch64/pr103147-1.C: Likewise.
            * g++.target/aarch64/pr103147-2.C: Likewise.
            * g++.target/aarch64/pr103147-3.C: Likewise.
            * g++.target/aarch64/pr103147-4.C: Likewise.
            * g++.target/aarch64/pr103147-5.C: Likewise.
            * g++.target/aarch64/pr103147-6.C: Likewise.
            * g++.target/aarch64/pr103147-7.C: Likewise.
            * g++.target/aarch64/pr103147-8.C: Likewise.
            * g++.target/aarch64/pr103147-9.C: Likewise.
            * g++.target/aarch64/pr103147-10.C: Likewise.

[Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed.