On 3/25/2022 3:51 AM, Richard Biener via Gcc-patches wrote:
We have
return VIEW_CONVERT_EXPR<U>( VEC_PERM_EXPR < {<<< Unknown tree:
compound_literal_expr
V D.1984 = { 0 }; >>>, { 0 }} , {<<< Unknown tree:
compound_literal_expr
V D.1985 = { 0 }; >>>, { 0 }} , { 0, 0 } > & {(short int) SAVE_EXPR <c>,
(short int) SAVE_EXPR <c>});
where we gimplify the init CTORs to
_1 = {{ 0 }, { 0 }};
_2 = {{ 0 }, { 0 }};
instead of to vector constants. That later runs into a bug in
uniform_vector_p which doesn't handle CTORs of vector elements
correctly.
The following adjusts uniform_vector_p to handle CTORs of vector
elements and also makes sure to simplify the CTORs to VECTOR_CSTs
during gimplification by re-ordering the simplification to after
CTOR flag recomputation.
Bootstrapped and tested on x86_64-unknown-linux-gnu. At this
point I'm leaning towards delaying the gimplification change
to stage1 - do you agree?
Thanks,
Richard.
2022-03-25 Richard Biener <rguent...@suse.de>
PR middle-end/105049
* gimplify.cc (gimplify_init_constructor): First gimplify,
then simplify the result to a VECTOR_CST.
* tree.cc (uniform_vector_p): Recurse for VECTOR_CST or
CONSTRUCTOR first elements.
* gcc/testsuite/gcc.dg/pr105049.c: New testcase.
Your call on the gimplify change, though I'd tend to lean towards
waiting unless we find that it's necessary to fix a regression. I'm
assuming the uniform_vector_p change fixes the reported bug and that the
gimplify change is more of a cleanup.
jeff