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

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

[admin@tho-otto.de]

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?

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

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
The m,0,s alternative exists since the beginning.

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

[admin@tho-otto.de]

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

--- Comment #2 from Thorsten Otto <admin@tho-otto.de> ---
Yes, i'm aware of that. And as already mentioned, the bug is not triggered by
all gcc versions. Is there something i can do to track down the issue?
tree-data-ref.cc is quite large.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |m68k-linux-gnu
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-09

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the preprocessed source of tree-data-ref.ii ?  That will remove
the second/third steps (andd needing a libc)?

This is mentioned in https://gcc.gnu.org/bugs/ after all.

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

[admin@tho-otto.de]

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

--- Comment #4 from Thorsten Otto <admin@tho-otto.de> ---
Created attachment 58150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58150&action=edit
preprocessed source & assembler output of tree-data-ref.cc

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever confirmed|1                           |0

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

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Thorsten Otto from comment #4)
> Created attachment 58150 [details]
> preprocessed source & assembler output of tree-data-ref.cc

You should be able to reduce this with cvise if you're willing.

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

[admin@tho-otto.de]

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

--- Comment #6 from Thorsten Otto <admin@tho-otto.de> ---
Oh, yes, of course.

command line that failed:
m68k-atari-mint-g++-14.1.0 -m68020-60 "-fno-PIE" "-c" "-O2"
"-fomit-frame-pointer" "-DIN_GCC" "-fno-exceptions" "-fno-rtti"
"-fasynchronous-unwind-tables" "-W" "-Wall" "-Wno-narrowing" "-Wwrite-strings"
"-Wcast-qual" "-Wmissing-format-attribute" "-Wconditionally-supported"
"-Woverloaded-virtual" "-pedantic" "-Wno-long-long" "-Wno-variadic-macros"
"-Wno-overlength-strings" "-DHAVE_CONFIG_H" "-fno-PIE" "-I." "-I."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/."
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcpp/include"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libcody"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber"
"-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libdecnumber/dpd"
"-I../libdecnumber" "-I/home/sebilla/m68k-atari-mint-gcc/gcc/../libbacktrace"
"-o" "tree-data-ref.o" "-save-temps"
"/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc"

(where /home/sebilla/m68k-atari-mint-gcc is the source directory of the repo)

The original cross-compiler (m68k-atari-mint-g++-14.1.0) was configured with:

/home/sebilla/m68k-atari-mint-gcc/configure --target=m68k-atari-mint
--build=x86_64-suse-linux-gnu --prefix=/usr --libdir=/usr/lib64
--bindir=/usr/bin --libexecdir='' 'CFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer
-include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h' CFLAGS='-O2
-fomit-frame-pointer -include /home/sebilla/m68k-atari-mint-gcc/gcc/libcwrap.h'
'CXXFLAGS_FOR_BUILD=-O2 -fomit-frame-pointer ' CXXFLAGS='-O2
-fomit-frame-pointer' 'BOOT_CFLAGS=-O2 -fomit-frame-pointer'
'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_TARGET=-O2
-fomit-frame-pointer' LDFLAGS_FOR_BUILD= LDFLAGS= GNATMAKE_FOR_HOST=gnatmake-14
GNATBIND_FOR_HOST=gnatbind-14 GNATLINK_FOR_HOST=gnatlink-14
--with-pkgversion='MiNT 20240507' --disable-libcc1 --disable-werror
--with-gxx-include-dir=/usr/m68k-atari-mint/sys-root/usr/include/c++/14
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-gcc-major-version-only
--with-gcc --with-gnu-as --with-gnu-ld --with-system-zlib
--without-static-standard-libraries --without-stage1-ldflags --disable-libgomp
--without-libatomic --without-newlib --disable-libstdcxx-pch --disable-threads
--disable-win32-registry --disable-lto --enable-ssp --enable-libssp
--disable-plugin --disable-decimal-float --disable-nls
--with-libiconv-prefix=/usr --with-libintl-prefix=/usr
--with-sysroot=/usr/m68k-atari-mint/sys-root
--enable-languages=c,c++,fortran,ada,d,m2

The compiler that i'm trying to build was configured with:

'--target=m68k-atari-mint' '--host=m68k-atari-mint'
'--build=x86_64-suse-linux-gnu' '--prefix=/usr' '--libdir=/usr/lib'
'--bindir=/usr/bin' '--libexecdir=${libdir}' '--with-pkgversion=MiNT 20240507'
'--disable-libcc1' '--disable-werror'
'--with-gxx-include-dir=/usr/include/c++/14'
'--with-libstdcxx-zoneinfo=/usr/share/zoneinfo' '--with-gcc-major-version-only'
'--with-gcc' '--with-gnu-as' '--with-gnu-ld' '--with-system-zlib'
'--disable-libgomp' '--without-newlib' '--disable-libstdcxx-pch'
'--disable-threads' '--disable-win32-registry' '--disable-lto' '--enable-ssp'
'--enable-libssp' '--disable-plugin' '--disable-decimal-float' '--disable-nls'
'--with-cpu=m68020-60' '--with-build-sysroot=/usr/m68k-atari-mint/sys-root'
'build_alias=x86_64-suse-linux-gnu' 'host_alias=m68k-atari-mint'
'target_alias=m68k-atari-mint' 'CC=m68k-atari-mint-gcc-14.1.0 -m68020-60'
'CFLAGS=-O2 -fomit-frame-pointer' 'LDFLAGS=-Wl,-stack,512k'
'CXX=m68k-atari-mint-g++-14.1.0 -m68020-60' 'CXXFLAGS=-O2 -fomit-frame-pointer'
'CC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'CXX_FOR_TARGET=m68k-atari-mint-g++-14.1.0'
'GCC_FOR_TARGET=m68k-atari-mint-gcc-14.1.0'
'GFORTRAN_FOR_TARGET=m68k-atari-mint-gfortran-14.1.0'
'GOC_FOR_TARGET=m68k-atari-mint-goc-14.1.0'
'AS_FOR_TARGET=/home/sebilla/mintstd/binary7-package/usr/bin/m68k-atari-mint-as'
'RANLIB_FOR_TARGET=m68k-atari-mint-ranlib'
'STRIP_FOR_TARGET=m68k-atari-mint-strip' '--enable-languages=c,c++'

compiler output was:

/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
siv_subscript_p(const_tree, const_tree)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3587:15: warning: this
statement may fall through [-Wimplicit-fallthrough=]
 3587 |               if (CHREC_VARIABLE (chrec_a) != CHREC_VARIABLE (chrec_b))
      |               ^~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:3591:13: note: here
 3591 |             default:
      |             ^~~~~~~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc: In function 'bool
get_references_in_stmt(gimple*, vec<data_ref_loc, va_heap>*)':
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:5888:25: warning: this
statement may fall through [-Wimplicit-fallthrough=]
 5888 |             ref.is_read = true;
      |             ~~~~~~~~~~~~^~~~~~
/home/sebilla/m68k-atari-mint-gcc/gcc/tree-data-ref.cc:5890:11: note: here
 5890 |           case IFN_MASK_STORE:
      |           ^~~~
tree-data-ref.s: Assembler messages:
tree-data-ref.s:16664: Error: operands mismatch -- statement `sub.l
-402(%fp),-446(%fp)' ignored
tree-data-ref.s:16813: Error: operands mismatch -- statement `sub.l
-274(%fp),-302(%fp)' ignored

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

[admin@tho-otto.de]

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

--- Comment #7 from Thorsten Otto <admin@tho-otto.de> ---
Created attachment 58151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58151&action=edit
Shortened test case

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

[admin@tho-otto.de]

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

--- Comment #8 from Thorsten Otto <admin@tho-otto.de> ---
I've never use cvise before, but it gave the attached short source. It inserted
a strange recursive call at the end, but it gives me these error messages:

test.c: In function 'void mul_hwi(bool*)':
test.c:4:6: warning: infinite recursion detected [-Winfinite-recursion]
    4 | void mul_hwi(bool *overflow) {
      |      ^~~~~~~
test.c:6:10: note: recursive call
    6 |   mul_hwi(&mul_hwi_ovf);
      |   ~~~~~~~^~~~~~~~~~~~~~
test.s: Assembler messages:
test.s:101: Error: operands mismatch -- statement `sub.l 80(%sp),52(%sp)'
ignored

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

[admin@tho-otto.de]

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

--- Comment #9 from Thorsten Otto <admin@tho-otto.de> ---
Doing some more testing:

- a cross-compiler build for m68k-suse-linux gives the same error on the
reduced testcase
- the error only occurs when using -m68020-60 or -m68060
- older compiler versions (tested gcc 13.2.0, gcc-12.3.0, gcc-11.4.0, and
gcc-10.5.0) do not give the error

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

[mikpelinux at gmail dot com]

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #10 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Reproduces with a cross to m68k-linux-gnu compiling the shortened test case
with -O2 -m68060. A git bisect between 13.2.0 and 14.1.0 identified the
following commit as introducing the misbehaviour:

d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd is the first new commit
commit d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Sun May 7 07:52:15 2023 +0100

    Don't call emit_clobber in lower-subreg.cc's resolve_simple_move.

Possibly it just exposes a latent issue in the target code.

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

[admin@tho-otto.de]

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

--- Comment #11 from Thorsten Otto <admin@tho-otto.de> ---
Confirmed, reverting that commit will prevent the error. Now the question is
how to find the real cause of the problem, since reverting that commit is most
likely not the solution. OTOH, it would be nice to know why the call to
emit_clobber() originally was done.

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

[admin@tho-otto.de]

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

--- Comment #12 from Thorsten Otto <admin@tho-otto.de> ---
Created attachment 58187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58187&action=edit
2nd test case

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

[admin@tho-otto.de]

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

--- Comment #13 from Thorsten Otto <admin@tho-otto.de> ---
Now its getting really strange. I've attached a 2nd test case above. With that,
the bug can be reproduced also with gcc 11.4.0 (but not with gcc-10, gcc-12 or
gcc-13).

It is slightly larger than the first case, but also has references to
__builtin_mul_overflow(). The 1st test case does not trigger the bug in gcc-11
though. 

Note that the commit that was identified as the culprit was only applied to the
gcc-14 branch, but not to gcc-11.

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

[admin@tho-otto.de]

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

--- Comment #14 from Thorsten Otto <admin@tho-otto.de> ---
A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit:

commit 512c6ba04102295fccc62a173ee0086ca733c920
From: Richard Biener <rguenther@suse.de>
Date: Thu, 12 Nov 2020 11:29:12 +0100
Subject: [PATCH] Avoid PRE insert iteration when possible

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

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Thorsten Otto from comment #14)
> A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit:
> 
> commit 512c6ba04102295fccc62a173ee0086ca733c920
> From: Richard Biener <rguenther@suse.de>
> Date: Thu, 12 Nov 2020 11:29:12 +0100
> Subject: [PATCH] Avoid PRE insert iteration when possible

That just shows it is a latent bug really since that touches gimple level and
not further down the pipeline of RTL.

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

[admin@tho-otto.de]

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

--- Comment #16 from Thorsten Otto <admin@tho-otto.de> ---
Yes, i'm just curious what that "latent bug" might be.

It might not have to do directly with that __builtin_mul_overflow() at all,
because when using -m68060, library calls to __mulsi3() are used to avoid the
32x32 muls.l instruction which is not implemented on 060. That makes less
registers available in the caller.