| Message ID | 01d501d64e65$adf69490$09e3bdb0$@nextmovesoftware.com |
|---|---|
| State | New |
| Headers | show |
| Series | PR middle-end/90597: gcc_assert ICE in layout_type | expand |
On Tue, Jun 30, 2020 at 12:38 AM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > It turns out that the ICE diagnosed/fixed in my earlier nvptx patch, caused by > TYPE_SIZE(type) being zero during error handling in gcc.dg/attr-vector_size.c > is actually fairly common among backends, and is known in bugzilla as > PR middle-end/90597, apparently a recent regression. > > The following patch should fix the default implementation of > TARGET_VECTOR_ALIGNMENT, known as default_vector_alignment, > using the same logic. This patch is relatively untested, a "make bootstrap" > on x86_64-pc-linux-gnu confirms that this code compiles without problems, > but doesn't actually exercise the code itself. > > OK for mainline? Thanks in advance to anyone who can confirm this patch > resolves the unexpected failure of gcc.dg/attr-vector_size.c on an affected > platform (i.e. a backend that doesn't define TARGET_VECTOR_ALIGNMENT). OK. > 2020-06-30 Roger Sayle <roger@nextmovesoftware.com> > > PR middle-end/90597 > gcc/ChangeLog: > * targhooks.c (default_vector_alignment): Return at least the > GET_MODE_ALIGNMENT for the type's mode. > > Thanks, > Roger > -- > Roger Sayle > NextMove Software > Cambridge, UK >
diff --git a/gcc/targhooks.c b/gcc/targhooks.c index 0113c7b..da4805d 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c @@ -1233,8 +1233,9 @@ default_vector_alignment (const_tree type) tree size = TYPE_SIZE (type); if (tree_fits_uhwi_p (size)) align = tree_to_uhwi (size); - - return align < MAX_OFILE_ALIGNMENT ? align : MAX_OFILE_ALIGNMENT; + if (align >= MAX_OFILE_ALIGNMENT) + return MAX_OFILE_ALIGNMENT; + return MAX (align, GET_MODE_ALIGNMENT (TYPE_MODE (type))); } /* The default implementation of