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

Reply via email to