https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676
--- Comment #21 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #19) > r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE, > r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs. > > I guess there is a disagreement between LRA and recog on how exactly they > treat register constraints. > "=lh" for TARGET_THUMB means LO_REGS or HI_REGS classes for the output, bet > LRA sees that LO_REGS or HI_REGS is together GENERAL_REGS and picks a > GENERAL_REGS > (reg:DI 7 r7 [orig:119 tmp ] [119]). But that one has one half in LO_REGS > and another half in HI_REGS and so extract_constrain_insn -> > constrain_operands > doesn't consider it as matching. Interesting case. To find required (reload) register class, LRA (as also the old reload pass) makes some union of register classes in one alternative which contains all or part of the registers of the classes (in this case it is general reg class). The problem can be solved w/o fixing LRA (and reload pass) by using asm volatile( "ldrd %Q[r], %R[r], %[p]\n" : [r]"=l,h"(tmp) : [p]"m,m"(*p64) : "memory" ); The problem can be solved in LRA by more complex representation of required reg classes (still reload should have also such fix). I guess it will complicate LRA and reload code a lot. We could also use more clear description of semantics of constraints currently used by LRA/reload. In this case we still need to output more meaningful error for LRA/reload instead of just internal compiler error.
