This is a problem I ran into before, although I can't remember the
details. The problem here is that a user program requests an
unreasonably large vector, the default_vector_alignment returns an
unreasonably large alignment in a HOST_WIDE_INT, which then gets stored
int TYPE_ALIGN, which is an int. Therefore TYPE_ALIGN becomes zero,
smaller than the type size, and we abort.
It seems misguided not to restrict alignments much more drastically in
this hook, but for now I chose what I think is a conservative fix:
limiting alignments to MAX_OFILE_ALIGNMENT.
Bootstrapped and tested on x86_64-linux. Ok?
Bernd
PR c/69973
* targhooks.c (default_vector_alignment): Limit to MAX_OFILE_ALIGNMENT.
testsuite/
PR c/69973
* gcc.dg/pr69973.c: New test.
Index: gcc/targhooks.c
===================================================================
--- gcc/targhooks.c (revision 233451)
+++ gcc/targhooks.c (working copy)
@@ -1031,7 +1031,10 @@ tree default_mangle_decl_assembler_name
HOST_WIDE_INT
default_vector_alignment (const_tree type)
{
- return tree_to_shwi (TYPE_SIZE (type));
+ HOST_WIDE_INT align = tree_to_shwi (TYPE_SIZE (type));
+ if (align > MAX_OFILE_ALIGNMENT)
+ align = MAX_OFILE_ALIGNMENT;
+ return align;
}
bool
Index: gcc/testsuite/gcc.dg/pr69973.c
===================================================================
--- gcc/testsuite/gcc.dg/pr69973.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr69973.c (working copy)
@@ -0,0 +1,2 @@
+/* { dg-do compile } */
+typedef int v4si __attribute__ ((vector_size (1 << 29)));
