https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
--- Comment #15 from Palmer Dabbelt <palmer at dabbelt dot com> --- Created attachment 40968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40968&action=edit glibc file that loops The suggested patch causes an infinate loop while building glibc for RISC-V. The preprocessed source is attached, but I think the right way to fix this might be to actually fix the int-in-FP problem in our backend. If I understand correctly we don't actually need riscv_preferred_reload_class() but I can instead remove all the integer->FP modes from the mov{q,h,s,d} patterns. With just static reg_class_t riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass) { return rclass; } (which I assume is the same as removing preferred_reload_class()) everything builds, but I haven't even bothered running the test suite yet. Looking at the mov patterns I can't actually find any that are illegal. I'm looking for something like [(set (match_operand:QI 0 "nonimmediate_operand" "=f") (match_operand:QI 1 "move_operand" " r"))] which would allow an integer to end up in a FP register, as opposed to [(set (match_operand:QI 0 "nonimmediate_operand" "=r") (match_operand:QI 1 "move_operand" " f"))] which from my understanding is legal, since we can store floats in GPRs. I can understand how the f-operand versions of movqi and movhi don't make any sense, so I'll get rid of those, but I think the all our others are OK? What am I missing?
