On 04/08/2015 11:07 AM, Jakub Jelinek wrote:
But that is how handle_aligned_attribute works, since forever (checked it
back to 3.2). In <= 3.4.x, it used to create it using build_type_copy,
since 4.0.0 using build_variant_type_copy, but both those routines behave
the same - build a type variant which is linked in the TYPE_NEXT_VARIANT
chain, and differs from the other type in there possibly just by
TYPE_ALIGN/TYPE_USER_ALIGN. Perhaps it should check TYPE_ALIGN only if
at least one of the two types has TYPE_USER_ALIGN set?
As for why TYPE_ATTRIBUTES are NULL, the reason for that is that
these are attributes on a typedef, so the attributes go into DECL_ATTRIBUTES
of the TYPE_DECL instead.
I see. So yes, I think we want to look at TYPE_USER_ALIGN as well.
Anyway, the P1 regression is just about the first hunk, so if you have
issues just with the second hunk and not the first hunk (from either of the
patches), I can just comment out the tests for alignof (const T), and open
a separate PR for that for later.
The second patch seems to cause a regression on c-c++-common/pr60226.c
because we avoid calling layout_type, so we lose the over-alignment
error. So the first hunk of the first patch is OK.
Incidentally, for template testcases it seems we also need to fix
layout_type and fixup_type_sizes to respect already-set TYPE_USER_ALIGN:
template <class T> struct A
{
T t;
};
typedef A<int> T[4] alignas (2 * alignof (int));
A<int> a[4];
typedef A<char> T2[4] alignas (2 * alignof (int));
#define SA(X) static_assert((X),#X)
SA(alignof (T) == 2 * alignof(int));
SA(alignof (T2) == 2 * alignof(int));
Jason
