When we expand BIT_FIELD_REF <x_2(D), 8, 8> we can end up creating
a stack local, running into the fix. But get_object_alignment
will return 8 for any SSA_NAME because that's not an "object" we
handle. Deal with handled components on registers by singling out
SSA_NAME bases, using their type alignment instead of
get_object_alignment (I considered "robustifying" get_object_alignment,
but decided not to at this point).
This fixes an ICE on gcc.dg/pr41123.c on arm as reported by the CI.
PR middle-end/118684
* expr.cc (expand_expr_real_1): When creating a stack local
during expansion of a handled component, when the base is
a SSA_NAME use its type alignment and avoid calling
get_object_alignment.
* gcc.dg/pr118684.c: Require automatic_stack_alignment.
if (!poly_int_tree_p (TYPE_SIZE_UNIT (TREE_TYPE (tem)), &size))
size = max_int_size_in_bytes (TREE_TYPE (tem));
memloc = assign_stack_local (TYPE_MODE (TREE_TYPE (tem)), size,
- get_object_alignment (tem));
+ TREE_CODE (tem) == SSA_NAME
+ ? TYPE_ALIGN (TREE_TYPE (tem))
+ : get_object_alignment (tem));
emit_move_insn (memloc, op0);
op0 = memloc;
clear_mem_expr = true;
-/* { dg-do run } */
+/* { dg-do run { target automatic_stack_alignment } } */
/* { dg-options "-O2" } */
typedef int v4si __attribute__((vector_size(16)));