PR middle-end/90597: gcc_assert ICE in layout_type

Message ID 01d501d64e65$adf69490$09e3bdb0$@nextmovesoftware.com
State New
Headers show
Series
  • PR middle-end/90597: gcc_assert ICE in layout_type
Related show

Commit Message

Roger Sayle June 29, 2020, 10:36 p.m.
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).

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

Patch

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