* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
@ 2021-11-09 7:13 ` pinskia at gcc dot gnu.org
2021-11-09 11:52 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-09 7:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
2021-11-09 7:13 ` [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct pinskia at gcc dot gnu.org
@ 2021-11-09 11:52 ` rguenth at gcc dot gnu.org
2022-02-08 17:01 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-09 11:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
2021-11-09 7:13 ` [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct pinskia at gcc dot gnu.org
2021-11-09 11:52 ` rguenth at gcc dot gnu.org
@ 2022-02-08 17:01 ` jakub at gcc dot gnu.org
2022-03-21 16:49 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-08 17:01 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
` (2 preceding siblings ...)
2022-02-08 17:01 ` jakub at gcc dot gnu.org
@ 2022-03-21 16:49 ` jakub at gcc dot gnu.org
2022-04-04 13:12 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-03-21 16:49 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
` (3 preceding siblings ...)
2022-03-21 16:49 ` jakub at gcc dot gnu.org
@ 2022-04-04 13:12 ` rguenth at gcc dot gnu.org
2022-04-04 13:50 ` rsandifo at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-04-04 13:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
` (4 preceding siblings ...)
2022-04-04 13:12 ` rguenth at gcc dot gnu.org
@ 2022-04-04 13:50 ` rsandifo at gcc dot gnu.org
2022-04-05 16:31 ` cvs-commit at gcc dot gnu.org
2022-04-05 16:41 ` rsandifo at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2022-04-04 13:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
` (5 preceding siblings ...)
2022-04-04 13:50 ` rsandifo at gcc dot gnu.org
@ 2022-04-05 16:31 ` cvs-commit at gcc dot gnu.org
2022-04-05 16:41 ` rsandifo at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-04-05 16:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug target/103147] [12 Regression] ICE in register_tuple_type with include "arm_neon.h" and -fpack-struct
2021-11-09 5:36 [Bug target/103147] New: ICE in register_tuple_type, at config/aarch64/aarch64-builtins.c:1313 asolokha at gmx dot com
` (6 preceding siblings ...)
2022-04-05 16:31 ` cvs-commit at gcc dot gnu.org
@ 2022-04-05 16:41 ` rsandifo at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2022-04-05 16:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread