diff options
author | Richard Biener <rguenther@suse.de> | 2023-04-24 13:20:25 +0200 |
---|---|---|
committer | Richard Biener <rguenther@suse.de> | 2023-04-27 13:16:48 +0200 |
commit | a82c6ab0aade4124e1903dda6f6f85c4c317fcec (patch) | |
tree | 4e355d53391fce8898093f58b941f806d004a632 /gcc/tree-ssa-phiopt.cc | |
parent | 0403d2957929fa12bbd379e3839a8d0c2160576f (diff) | |
download | gcc-a82c6ab0aade4124e1903dda6f6f85c4c317fcec.zip gcc-a82c6ab0aade4124e1903dda6f6f85c4c317fcec.tar.gz gcc-a82c6ab0aade4124e1903dda6f6f85c4c317fcec.tar.bz2 |
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.
Diffstat (limited to 'gcc/tree-ssa-phiopt.cc')
0 files changed, 0 insertions, 0 deletions