https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108516
Hongtao.liu <crazylht at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |crazylht at gmail dot com
--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
> Hmm, is this even valid RTL that combine is producing ...
If it's valid for different modes between zero_extract and mode of {loc}, we
can directly add an insn to match that.
The documents doesn't mention any requirement for mode {m} and {loc}
2892@findex zero_extract
2893@item (zero_extract:@var{m} @var{loc} @var{size} @var{pos})
2894Like @code{sign_extract} but refers to an unsigned or zero-extended
2895bit-field. The same sequence of bits are extracted, but they
2896are filled to an entire word with zeros instead of by sign-extension.
2897
2898Unlike @code{sign_extract}, this type of expressions can be lvalues
2899in RTL; they may appear on the left side of an assignment, indicating
2900insertion of a value into the specified bit-field.
2901@end table
