* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
@ 2024-05-09 14:50 ` schwab@linux-m68k.org
2024-05-09 15:13 ` admin@tho-otto.de
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: schwab@linux-m68k.org @ 2024-05-09 14:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
2024-05-09 14:50 ` [Bug target/115010] " schwab@linux-m68k.org
@ 2024-05-09 15:13 ` admin@tho-otto.de
2024-05-09 16:11 ` pinskia at gcc dot gnu.org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 15:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
2024-05-09 14:50 ` [Bug target/115010] " schwab@linux-m68k.org
2024-05-09 15:13 ` admin@tho-otto.de
@ 2024-05-09 16:11 ` pinskia at gcc dot gnu.org
2024-05-09 16:32 ` admin@tho-otto.de
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-09 16:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (2 preceding siblings ...)
2024-05-09 16:11 ` pinskia at gcc dot gnu.org
@ 2024-05-09 16:32 ` admin@tho-otto.de
2024-05-09 16:33 ` pinskia at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 16:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (3 preceding siblings ...)
2024-05-09 16:32 ` admin@tho-otto.de
@ 2024-05-09 16:33 ` pinskia at gcc dot gnu.org
2024-05-09 16:34 ` sjames at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-09 16:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (4 preceding siblings ...)
2024-05-09 16:33 ` pinskia at gcc dot gnu.org
@ 2024-05-09 16:34 ` sjames at gcc dot gnu.org
2024-05-09 16:46 ` admin@tho-otto.de
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-09 16:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (5 preceding siblings ...)
2024-05-09 16:34 ` sjames at gcc dot gnu.org
@ 2024-05-09 16:46 ` admin@tho-otto.de
2024-05-09 17:15 ` admin@tho-otto.de
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 16:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (6 preceding siblings ...)
2024-05-09 16:46 ` admin@tho-otto.de
@ 2024-05-09 17:15 ` admin@tho-otto.de
2024-05-09 17:17 ` admin@tho-otto.de
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 17:15 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (7 preceding siblings ...)
2024-05-09 17:15 ` admin@tho-otto.de
@ 2024-05-09 17:17 ` admin@tho-otto.de
2024-05-09 18:51 ` admin@tho-otto.de
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 17:17 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (8 preceding siblings ...)
2024-05-09 17:17 ` admin@tho-otto.de
@ 2024-05-09 18:51 ` admin@tho-otto.de
2024-05-12 15:24 ` mikpelinux at gmail dot com
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-09 18:51 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (9 preceding siblings ...)
2024-05-09 18:51 ` admin@tho-otto.de
@ 2024-05-12 15:24 ` mikpelinux at gmail dot com
2024-05-13 3:20 ` admin@tho-otto.de
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mikpelinux at gmail dot com @ 2024-05-12 15:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (10 preceding siblings ...)
2024-05-12 15:24 ` mikpelinux at gmail dot com
@ 2024-05-13 3:20 ` admin@tho-otto.de
2024-05-13 9:52 ` admin@tho-otto.de
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-13 3:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (11 preceding siblings ...)
2024-05-13 3:20 ` admin@tho-otto.de
@ 2024-05-13 9:52 ` admin@tho-otto.de
2024-05-13 10:01 ` admin@tho-otto.de
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-13 9:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (12 preceding siblings ...)
2024-05-13 9:52 ` admin@tho-otto.de
@ 2024-05-13 10:01 ` admin@tho-otto.de
2024-05-13 11:35 ` admin@tho-otto.de
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-13 10:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (13 preceding siblings ...)
2024-05-13 10:01 ` admin@tho-otto.de
@ 2024-05-13 11:35 ` admin@tho-otto.de
2024-05-23 5:03 ` pinskia at gcc dot gnu.org
2024-05-23 5:17 ` admin@tho-otto.de
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-13 11:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (14 preceding siblings ...)
2024-05-13 11:35 ` admin@tho-otto.de
@ 2024-05-23 5:03 ` pinskia at gcc dot gnu.org
2024-05-23 5:17 ` admin@tho-otto.de
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-05-23 5:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug target/115010] m68k: invalid subl instruction generated
2024-05-09 12:21 [Bug target/115010] New: m68k: invalid subl instruction generated admin@tho-otto.de
` (15 preceding siblings ...)
2024-05-23 5:03 ` pinskia at gcc dot gnu.org
@ 2024-05-23 5:17 ` admin@tho-otto.de
16 siblings, 0 replies; 18+ messages in thread
From: admin@tho-otto.de @ 2024-05-23 5:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 18+ messages in thread