[Bug target/115010] New: m68k: invalid subl instruction generated

["admin@tho-otto.de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010

            Bug ID: 115010
           Summary: m68k: invalid subl instruction generated
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: admin@tho-otto.de
  Target Milestone: ---

While configuring a cross-compiler for m68k, and then trying to use that
cross-compiler to build a native compiler, a wrong subl instruction gets
generated:

Assembler messages:
    /tmp/ccpLXgrk.s:16664: Error: operands mismatch -- statement sub.l
-402(%fp),-446(%fp)' ignored
    /tmp/ccpLXgrk.s:16813: Error: operands mismatch -- statement sub.l
-274(%fp),-302(%fp)' ignored
    make[1]: *** [Makefile:1202: tree-data-ref.o] Error 1

That instruction is invalid, because atleast one of the operands must be a data
register.

Unfortunately the steps to reproduce are a bit complicated, using a bare
m68k-elf target not work, because for the 2nd step you will also need a working
c-library. And of course you also need binutils for that target.

I should also mention that the same bug already happened in gcc 11.4.0, but
strangely not in gcc 13.2.0 or gcc 12.3.0 (but maybe this was just by
incident).
The problem also disappears when compiling tree-data-ref.c using -Os instead of
-O2.

I'm not that really familiar with the machine description files, but to me

(define_insn "subsi3"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=md,ma,m,d,a")
        (minus:SI (match_operand:SI 1 "general_operand" "0,0,0,0,0")
                  (match_operand:SI 2 "general_src_operand"
"I,I,dT,mSrT,mSrs")))]
  ""
  "@
   subq%.l %2, %0
   subq%.l %2, %0
   sub%.l %2,%0
   sub%.l %2,%0
   sub%.l %2,%0"
  [(set_attr "type" "aluq_l,aluq_l,alu_l,alu_l,alu_l")
   (set_attr "opy" "2")
   (set_attr "flags_valid" "noov,unchanged,noov,noov,unchanged")])


Looks suspicious. If i'm not wrong, that pattern is used to turn something like
"x = x - y" into "x -= y". But alternative 3 can match a memory operand for
operand 0, and constraint 'T' for operand 2 is defined as

(define_constraint "T"
  "Used for operands that satisfy 's' when -mpcrel is not in effect."
  (and (match_code "symbol_ref,label_ref,const")
       (match_test "!TARGET_PCREL")
       (match_test "!flag_pic || LEGITIMATE_PIC_OPERAND_P (op)")))

so it can match a symbol_ref. Could that be the cause?