https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is another bug, in darktable actually such overaligned pointer isn't
passed, but it is cvise reduced into:
$ cat color_picker.c
void
bar (void)
{
float *__attribute__((aligned(64))) x;
}
$ cat color_vocabulary.c
int a, b, c;
void
foo (void)
{
c = __builtin_cosf (2.0f * 3.14159265358979324f * a);
b = __builtin_sinf (2.0f * 3.14159265358979324f * a);
}
$ ./xgcc -B ./ -c -flto=auto -ffat-lto-objects -g -O3 -ffast-math
-fno-finite-math-only -fPIC -fexpensive-optimizations color_picker.c
$ ./xgcc -B ./ -c -flto=auto -ffat-lto-objects -g -O3 -ffast-math
-fno-finite-math-only -fPIC -fexpensive-optimizations color_vocabulary.c
$ ./xgcc -B ./ -flto=auto -ffat-lto-objects -o color_picker -r color_picker.o
color_vocabulary.o
during RTL pass: expand
color_vocabulary.c: In function ‘foo’:
color_vocabulary.c:4:1: internal compiler error: in aarch64_layout_arg, at
config/aarch64/aarch64.cc:7688
4 | foo (void)
| ^
0x118d493 aarch64_layout_arg
../../gcc/config/aarch64/aarch64.cc:7688
0x118dd7a aarch64_function_arg
../../gcc/config/aarch64/aarch64.cc:7868
0x92080b initialize_argument_information
../../gcc/calls.cc:1499
0x925273 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.cc:2973
0x90a2da expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:8452
0xa5ecfe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11872
0x8f638d expand_builtin_cexpi
../../gcc/builtins.cc:2685
0x9077ee expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:7476
0xa5ecfe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11872
0xa694b5 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.cc:6333
0xa6bbf0 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.cc:6051
0x93866a expand_call_stmt
../../gcc/cfgexpand.cc:2829
0x93866a expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0x93866a expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x93e0c6 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x93fa67 execute
../../gcc/cfgexpand.cc:6831
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: ./xgcc returned 1 exit status
compilation terminated.
/usr/bin/aarch64-linux-gnu-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Now, I believe the reason why this #c0 bug triggers even when the aligned (64)
pointer appears in completely unrelated function
is that while without LTO, TYPE_POINTER_TO/TYPE_NEXT_PTR_TO is only registered
for types actually created with build_pointer_type_for_mode,
so pretty much for type with basic alignment, no extra attributes, no
cv-qualification/TYPE_ADDR_SPACE etc. (note, I'm talking
about the POINTER_TYPE, not what it points to), during LTO streaming in that is
all of sudden not the case.
LTO streaming itself doesn't do anything about those, but then
lto_fixup_prevailing_type can add there some other POINTER_TYPE
which as in the testcase has TYPE_USER_ALIGN, or could have any other weird
stuff. I think we should add to TYPE_POINTER_TO
chain only if it is really a pointer type without any of those extras and only
if such a type doesn't appear in the chain already.
