| Message ID | 56DA207B.9000508@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 03/04/2016 04:55 PM, Bernd Schmidt wrote: > 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 > > valign.diff > > > PR c/69973 > * targhooks.c (default_vector_alignment): Limit to MAX_OFILE_ALIGNMENT. > > testsuite/ > PR c/69973 > * gcc.dg/pr69973.c: New test. This is safe enough that even though it's not a regression I think it's fine for gcc-6. I'll commit to the trunk momentarily. jeff
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)));