https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63764
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the #c4 testcase, it is even unclear to me whether we shouldn't reject it.
typedef float V __attribute__((vector_size (4 * sizeof (float))));
void
fn2 ()
{
V saijplus16 = (V) { 0.0, 0.0, 0.0, 0.0 };
((V) saijplus16)[0] = 0;
}
doesn't ICE (at least on x86_64) though,
void
fn3 ()
{
float __attribute__((vector_size (4 * sizeof (float)))) saijplus16 = (float
__attribute__((vector_size (4 * sizeof (float))))) { 0.0, 0.0, 0.0, 0.0 };
((float __attribute__((vector_size (4 * sizeof (float))))) saijplus16)[0] =
0;
}
does. The difference is when
handling the (type) saijplus16 cast in build_c_cast.
In the ppc case and fn3 case, the type is the same, so we end up with
NON_LVALUE_EXPR of saijplus16. In the fn2 case with V typedef, the type is
different (saijplus16 has V type, the cast uses its main variant), so we end up
with VIEW_CONVERT_EXPR of saijplus16 instead. The VCE gets folded away, while
NON_LVALUE_EXPR remains. But in all cases the casts aren't valid lvalue.
Note, C++ ICEs on all the testcases.
IMHO either we need to reject it (but how to find out in the case of
build_c_cast that it originally was non-lvalue?), or we need to skip the
NON_LVALUE_EXPRs when marking the var as addressable and taking address of it.
