From a82c6ab0aade4124e1903dda6f6f85c4c317fcec Mon Sep 17 00:00:00 2001 From: Richard Biener Date: Mon, 24 Apr 2023 13:20:25 +0200 Subject: [PATCH] wrong GIMPLE from (bit_field_ref CTOR ..) simplification When we simplify a BIT_FIELD_REF of a CTOR like { _1, _2, _3, _4 } and attempt to produce (view converted) { _1, _2 } for a selected subset we fail to realize this cannot be done from match.pd since we have no way to write the resulting CTOR "operation" and the built CTOR { _1, _2 } isn't a GIMPLE value. This kind of simplifications have to be done in forwprop (or would need a match.pd syntax extension) where we can split out the CTOR to a separate stmt. The following disables this particular simplification when we are simplifying GIMPLE. With enhanced IL checking this otherwise causes ICEs in the testsuite from vectorized code. * match.pd (BIT_FIELD_REF CONSTRUCTOR@0 @1 @2): Do not create a CTOR operand in the result when simplifying GIMPLE. --- gcc/match.pd | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/gcc/match.pd b/gcc/match.pd index 34e1a5c1b46c..c4320781f5b8 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7456,10 +7456,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) ? type : build_vector_type (TREE_TYPE (TREE_TYPE (ctor)), count * k)); + /* We used to build a CTOR in the non-constant case here + but that's not a GIMPLE value. We'd have to expose this + operation somehow so the code generation can properly + split it out to a separate stmt. */ res = (constant_p ? build_vector_from_ctor (evtype, vals) - : build_constructor (evtype, vals)); + : (GIMPLE ? NULL_TREE : build_constructor (evtype, vals))); } - (view_convert { res; })))))) + (if (res) + (view_convert { res; }))))))) /* The bitfield references a single constructor element. */ (if (k.is_constant (&const_k) && idx + n <= (idx / const_k + 1) * const_k) -- 2.47.2