https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Sure, before that we would punt much earlier at simplification of the non-sensical subreg. I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases where it ICEs and instead fails. But, I believe what gen_lowpart_for_combine does for comparisons is completely wrong for non-scalar modes that are different from their previous mode. A same sized subreg of something is reinterpretation of the bits of something as something else, VIEW_CONVERT_EXPR or type punning through union. Changing the mode of a comparison isn't like that. Consider: typedef char __v8qi __attribute__((vector_size (8))); void foo (int x, __v8qi *y) { union U { __v8qi v; unsigned long long l; } u; u.l = x > 36; *y = *y + u.v; } on x86_64-linux, I see (subreg:V8QI (gt:DI (reg:CCGC 17 flags) (const_int 0 [0])) 0) in the dumps but for some reason gen_lowpart_for_combine actually hasn't been called except to convert originally gt:QI to gt:DI (that is correct). If it would be called, it would turn it into a completely bogus (gt:V8QI (reg:CCGC 17 flags) (const_int 0 [0])), which isn't clear what it actually would mean. (gt:V8QI (reg:V8QI ...) (reg:V8QI ...)) performs 8 comparisons and fills in the resulting vector with 8 0/-1 values, similarly (gt:V8QI (reg:V8QI ...) (const_vector:V8QI ...)). But if both operands of the comparison are scalar and result is a vector, what it is?