* Re: [PATCH 0/4] Eliminate cc0 from m68k
@ 2019-11-17 16:19 Mikael Pettersson
2019-11-17 16:58 ` Andreas Schwab
2019-11-21 14:36 ` John Paul Adrian Glaubitz
0 siblings, 2 replies; 36+ messages in thread
From: Mikael Pettersson @ 2019-11-17 16:19 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: GCC Patches
On Wed, 13 Nov 2019 14:04:59 +0100, Bernd Schmidt
<bernds_cb1@t-online.de> wrote:
> This is a set of patches to convert m68k so that it no longer uses cc0.
Thank you for doing this. I attempted a native bootstrap of
gcc-10-20191110 (r278028) plus the five patches posted so far on
m68k-linux (aranym), but it failed in stage 2:
/mnt/scratch/objdir10/./prev-gcc/xg++
-B/mnt/scratch/objdir10/./prev-gcc/
-B/mnt/scratch/install10/m68k-unknown-linux-gnu/bin/ -nostdinc++
-B/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu
-I/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/include
-I/mnt/scratch/gcc-10-20191110/libstdc++-v3/libsupc++
-L/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/mnt/scratch/objdir10/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-10-20191110/gcc
-I/mnt/scratch/gcc-10-20191110/gcc/.
-I/mnt/scratch/gcc-10-20191110/gcc/../include
-I/mnt/scratch/gcc-10-20191110/gcc/../libcpp/include
-I/mnt/scratch/gcc-10-20191110/gcc/../libdecnumber
-I/mnt/scratch/gcc-10-20191110/gcc/../libdecnumber/dpd
-I../libdecnumber -I/mnt/scratch/gcc-10-20191110/gcc/../libbacktrace
-o dbxout.o -MT dbxout.o -MMD -MP -MF ./.deps/dbxout.TPo
/mnt/scratch/gcc-10-20191110/gcc/dbxout.c
/tmp/ccJA1qws.s: Assembler messages:
/tmp/ccJA1qws.s:4828: Error: operands mismatch -- statement `seq %a1' ignored
/tmp/ccJA1qws.s:7344: Error: operands mismatch -- statement `seq %a1' ignored
Makefile:1118: recipe for target 'dbxout.o' failed
make[3]: *** [dbxout.o] Error 1
make[3]: Leaving directory '/mnt/scratch/objdir10/gcc'
Makefile:4740: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/mnt/scratch/objdir10'
Makefile:20204: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/mnt/scratch/objdir10'
Makefile:20399: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2
An Scc instruction cannot have an address register as destination operand.
I don't have a reduced test case, but the error can be reproduced by
building a cross gcc to m68k-linux and then using that to build a
native gcc for m68k-linux.
/Mikael
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-17 16:19 [PATCH 0/4] Eliminate cc0 from m68k Mikael Pettersson @ 2019-11-17 16:58 ` Andreas Schwab 2019-11-17 18:04 ` Jeff Law 2019-11-17 19:45 ` Mikael Pettersson 2019-11-21 14:36 ` John Paul Adrian Glaubitz 1 sibling, 2 replies; 36+ messages in thread From: Andreas Schwab @ 2019-11-17 16:58 UTC (permalink / raw) To: Mikael Pettersson; +Cc: Bernd Schmidt, GCC Patches On Nov 17 2019, Mikael Pettersson wrote: > /tmp/ccJA1qws.s:4828: Error: operands mismatch -- statement `seq %a1' ignored > /tmp/ccJA1qws.s:7344: Error: operands mismatch -- statement `seq %a1' ignored That should fix it: diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md index 0cf063aaf84..3efcaad33a4 100644 --- a/gcc/config/m68k/m68k.md +++ b/gcc/config/m68k/m68k.md @@ -698,7 +698,7 @@ }) (define_insn "cstore_bftst<mode>_insn" - [(set (match_operand:QI 0 "register_operand") + [(set (match_operand:QI 0 "register_operand" "=d") (match_operator:QI 1 "ordered_comparison_operator" [(zero_extract:SI (match_operand:BTST 2 "<btst_predicate>" "<btst_constraint>") (match_operand:SI 3 "const_int_operand" "n") Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-17 16:58 ` Andreas Schwab @ 2019-11-17 18:04 ` Jeff Law 2019-11-17 19:45 ` Mikael Pettersson 1 sibling, 0 replies; 36+ messages in thread From: Jeff Law @ 2019-11-17 18:04 UTC (permalink / raw) To: Andreas Schwab, Mikael Pettersson; +Cc: Bernd Schmidt, GCC Patches On 11/17/19 9:57 AM, Andreas Schwab wrote: > On Nov 17 2019, Mikael Pettersson wrote: > >> /tmp/ccJA1qws.s:4828: Error: operands mismatch -- statement `seq %a1' ignored >> /tmp/ccJA1qws.s:7344: Error: operands mismatch -- statement `seq %a1' ignored > > That should fix it: > > diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md > index 0cf063aaf84..3efcaad33a4 100644 > --- a/gcc/config/m68k/m68k.md > +++ b/gcc/config/m68k/m68k.md > @@ -698,7 +698,7 @@ > }) > > (define_insn "cstore_bftst<mode>_insn" > - [(set (match_operand:QI 0 "register_operand") > + [(set (match_operand:QI 0 "register_operand" "=d") > (match_operator:QI 1 "ordered_comparison_operator" > [(zero_extract:SI (match_operand:BTST 2 "<btst_predicate>" "<btst_constraint>") > (match_operand:SI 3 "const_int_operand" "n") OK. Bernd, presumably you can add this minor bugfix on top of your kit when you install it? Jeff ps. And to answer a question of Bernd's from a prior message. I'm not bootstrapping on real m68k hardware. I'm using qemu user space emulation + a native m68k chroot environment. I've also used Aranym in the past with good success. I prefer the former because it's the same core technology as other targets *and* since I'm just using user mode emulation I can exploit whatever SMP resources are on the host. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-17 16:58 ` Andreas Schwab 2019-11-17 18:04 ` Jeff Law @ 2019-11-17 19:45 ` Mikael Pettersson 2019-11-18 19:39 ` Bernd Schmidt 1 sibling, 1 reply; 36+ messages in thread From: Mikael Pettersson @ 2019-11-17 19:45 UTC (permalink / raw) To: Andreas Schwab; +Cc: Bernd Schmidt, GCC Patches On Sun, Nov 17, 2019 at 5:57 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Nov 17 2019, Mikael Pettersson wrote: > > > /tmp/ccJA1qws.s:4828: Error: operands mismatch -- statement `seq %a1' ignored > > /tmp/ccJA1qws.s:7344: Error: operands mismatch -- statement `seq %a1' ignored > > That should fix it: > > diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md > index 0cf063aaf84..3efcaad33a4 100644 > --- a/gcc/config/m68k/m68k.md > +++ b/gcc/config/m68k/m68k.md > @@ -698,7 +698,7 @@ > }) > > (define_insn "cstore_bftst<mode>_insn" > - [(set (match_operand:QI 0 "register_operand") > + [(set (match_operand:QI 0 "register_operand" "=d") > (match_operator:QI 1 "ordered_comparison_operator" > [(zero_extract:SI (match_operand:BTST 2 "<btst_predicate>" "<btst_constraint>") > (match_operand:SI 3 "const_int_operand" "n") > > Andreas. This fixed the problem, thanks. /Mikael ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-17 19:45 ` Mikael Pettersson @ 2019-11-18 19:39 ` Bernd Schmidt 2019-11-18 20:57 ` Mikael Pettersson 0 siblings, 1 reply; 36+ messages in thread From: Bernd Schmidt @ 2019-11-18 19:39 UTC (permalink / raw) To: Mikael Pettersson, Andreas Schwab; +Cc: GCC Patches Hi Mikael, > This fixed the problem, thanks. Could you also run the testsuite to see if you can reproduce the g++.old-deja failures Andreas reported? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-18 19:39 ` Bernd Schmidt @ 2019-11-18 20:57 ` Mikael Pettersson 2019-11-20 13:52 ` Mikael Pettersson 0 siblings, 1 reply; 36+ messages in thread From: Mikael Pettersson @ 2019-11-18 20:57 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Andreas Schwab, GCC Patches On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: > > Hi Mikael, > > > This fixed the problem, thanks. > > Could you also run the testsuite to see if you can reproduce the > g++.old-deja failures Andreas reported? Yes, but it will probably take another week before the native bootstrap (on aranym) and test suite run is finished. It's currently in stage 2. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-18 20:57 ` Mikael Pettersson @ 2019-11-20 13:52 ` Mikael Pettersson 2019-11-20 14:29 ` Bernd Schmidt 0 siblings, 1 reply; 36+ messages in thread From: Mikael Pettersson @ 2019-11-20 13:52 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Andreas Schwab, GCC Patches On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson <mikpelinux@gmail.com> wrote: > > On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: > > > > Hi Mikael, > > > > > This fixed the problem, thanks. > > > > Could you also run the testsuite to see if you can reproduce the > > g++.old-deja failures Andreas reported? > > Yes, but it will probably take another week before the native > bootstrap (on aranym) and test suite run is finished. It's currently > in stage 2. Failed later in stage 2: /mnt/scratch/objdir10/./gcc/xgcc -B/mnt/scratch/objdir10/./gcc/ -B/mnt/scratch/install10/m68k-unknown-linux-gnu/bin/ -B/mnt/scratch/install10/m68k-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install10/m68k-unknown-linux-gnu/include -isystem /mnt/scratch/install10/m68k-unknown-linux-gnu/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I/mnt/scratch/gcc-10-20191110/libgcc -I/mnt/scratch/gcc-10-20191110/libgcc/. -I/mnt/scratch/gcc-10-20191110/libgcc/../gcc -I/mnt/scratch/gcc-10-20191110/libgcc/../include -DHAVE_CC_TLS -o _powixf2.o -MT _powixf2.o -MD -MP -MF _powixf2.dep -DL_powixf2 -c /mnt/scratch/gcc-10-20191110/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /mnt/scratch/gcc-10-20191110/libgcc/libgcc2.c: In function '__powixf2': /mnt/scratch/gcc-10-20191110/libgcc/libgcc2.c:1888:1: error: unrecognizable insn: 1888 | } | ^ (insn 116 115 117 13 (parallel [ (set (reg/f:SI 15 %sp) (plus:SI (reg/f:SI 15 %sp) (const_int -12 [0xfffffffffffffff4]))) (set (reg:XF 18 %fp2) (mem/c:XF (reg/f:SI 15 %sp) [3 S12 A8])) ]) "/mnt/scratch/gcc-10-20191110/libgcc/libgcc2.c":1888:1 -1 (nil)) during RTL pass: cprop_hardreg /mnt/scratch/gcc-10-20191110/libgcc/libgcc2.c:1888:1: internal compiler error: in extract_insn, at recog.c:2294 Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. Makefile:500: recipe for target '_powixf2.o' failed make[3]: *** [_powixf2.o] Error 1 make[3]: Leaving directory '/mnt/scratch/objdir10/m68k-unknown-linux-gnu/libgcc' Makefile:16905: recipe for target 'all-stage2-target-libgcc' failed make[2]: *** [all-stage2-target-libgcc] Error 2 make[2]: Leaving directory '/mnt/scratch/objdir10' Makefile:20204: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/mnt/scratch/objdir10' Makefile:20399: recipe for target 'bootstrap' failed make: *** [bootstrap] Error 2 I'll try to reduce it to a test case later today. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 13:52 ` Mikael Pettersson @ 2019-11-20 14:29 ` Bernd Schmidt 2019-11-20 16:59 ` Jeff Law 2019-11-20 20:04 ` Mikael Pettersson 0 siblings, 2 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-20 14:29 UTC (permalink / raw) To: Mikael Pettersson; +Cc: Andreas Schwab, GCC Patches On 11/20/19 2:50 PM, Mikael Pettersson wrote: > On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson <mikpelinux@gmail.com> wrote: >> >> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: >>> >>> Hi Mikael, >>> >>>> This fixed the problem, thanks. >>> >>> Could you also run the testsuite to see if you can reproduce the >>> g++.old-deja failures Andreas reported? >> >> Yes, but it will probably take another week before the native >> bootstrap (on aranym) and test suite run is finished. It's currently >> in stage 2. Ugh, that suggests the stage2 compiler was miscompiled. That would be nasty to track down. Probably best to just run tests on stage1 and hope something shows up. What distro are you using for native builds? The m68k debian I'm using does not have an installable gcc package. Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 14:29 ` Bernd Schmidt @ 2019-11-20 16:59 ` Jeff Law 2019-11-20 20:04 ` Mikael Pettersson 1 sibling, 0 replies; 36+ messages in thread From: Jeff Law @ 2019-11-20 16:59 UTC (permalink / raw) To: Bernd Schmidt, Mikael Pettersson; +Cc: Andreas Schwab, GCC Patches On 11/20/19 7:16 AM, Bernd Schmidt wrote: > On 11/20/19 2:50 PM, Mikael Pettersson wrote: >> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson <mikpelinux@gmail.com> wrote: >>> >>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: >>>> >>>> Hi Mikael, >>>> >>>>> This fixed the problem, thanks. >>>> >>>> Could you also run the testsuite to see if you can reproduce the >>>> g++.old-deja failures Andreas reported? >>> >>> Yes, but it will probably take another week before the native >>> bootstrap (on aranym) and test suite run is finished. It's currently >>> in stage 2. > > Ugh, that suggests the stage2 compiler was miscompiled. That would be > nasty to track down. > > Probably best to just run tests on stage1 and hope something shows up. > > What distro are you using for native builds? The m68k debian I'm using > does not have an installable gcc package. Definitely agreed, best place to start is with teh stage1 testresults and see if we can nail it down that way. Debugging user mode qemu bits is *painful*. For that we may ultimately be better off with Aranym. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 14:29 ` Bernd Schmidt 2019-11-20 16:59 ` Jeff Law @ 2019-11-20 20:04 ` Mikael Pettersson 2019-11-20 20:29 ` Jeff Law 2019-11-20 20:50 ` Bernd Schmidt 1 sibling, 2 replies; 36+ messages in thread From: Mikael Pettersson @ 2019-11-20 20:04 UTC (permalink / raw) To: Bernd Schmidt; +Cc: Andreas Schwab, GCC Patches On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: > > On 11/20/19 2:50 PM, Mikael Pettersson wrote: > > On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson <mikpelinux@gmail.com> wrote: > >> > >> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: > >>> > >>> Hi Mikael, > >>> > >>>> This fixed the problem, thanks. > >>> > >>> Could you also run the testsuite to see if you can reproduce the > >>> g++.old-deja failures Andreas reported? > >> > >> Yes, but it will probably take another week before the native > >> bootstrap (on aranym) and test suite run is finished. It's currently > >> in stage 2. > > Ugh, that suggests the stage2 compiler was miscompiled. That would be > nasty to track down. > > Probably best to just run tests on stage1 and hope something shows up. Ok, how do I did that? I've always just done 'make -k check' after full bootstraps. I assume the stage 1 artifacts are the ones in the prev-* directories. > What distro are you using for native builds? The m68k debian I'm using > does not have an installable gcc package. I run a bespoke distro on m68k and sparc64, derived from Fedora but massively cut down in size, with target patches done by myself or ported from Debian and Gentoo as necessary. Debian/m68k not having a gcc package? That sounds odd; I see e.g. a gcc-9 in http://ftp.ports.debian.org/debian-ports/pool-m68k/main/g/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 20:04 ` Mikael Pettersson @ 2019-11-20 20:29 ` Jeff Law 2019-11-20 20:50 ` Bernd Schmidt 1 sibling, 0 replies; 36+ messages in thread From: Jeff Law @ 2019-11-20 20:29 UTC (permalink / raw) To: Mikael Pettersson, Bernd Schmidt; +Cc: Andreas Schwab, GCC Patches On 11/20/19 12:27 PM, Mikael Pettersson wrote: > On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt > <bernds_cb1@t-online.de> wrote: >> >> On 11/20/19 2:50 PM, Mikael Pettersson wrote: >>> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson >>> <mikpelinux@gmail.com> wrote: >>>> >>>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt >>>> <bernds_cb1@t-online.de> wrote: >>>>> >>>>> Hi Mikael, >>>>> >>>>>> This fixed the problem, thanks. >>>>> >>>>> Could you also run the testsuite to see if you can reproduce >>>>> the g++.old-deja failures Andreas reported? >>>> >>>> Yes, but it will probably take another week before the native >>>> bootstrap (on aranym) and test suite run is finished. It's >>>> currently in stage 2. >> >> Ugh, that suggests the stage2 compiler was miscompiled. That would >> be nasty to track down. >> >> Probably best to just run tests on stage1 and hope something shows >> up. > > Ok, how do I did that? I've always just done 'make -k check' after > full bootstraps. I assume the stage 1 artifacts are the ones in the > prev-* directories. I do something like this make all-gcc && make all-target-libgcc cd gcc make check-gcc Jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 20:04 ` Mikael Pettersson 2019-11-20 20:29 ` Jeff Law @ 2019-11-20 20:50 ` Bernd Schmidt 2019-11-20 22:18 ` Richard Earnshaw 1 sibling, 1 reply; 36+ messages in thread From: Bernd Schmidt @ 2019-11-20 20:50 UTC (permalink / raw) To: Mikael Pettersson; +Cc: Andreas Schwab, GCC Patches On 11/20/19 8:27 PM, Mikael Pettersson wrote: > On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: >> Probably best to just run tests on stage1 and hope something shows up. > > Ok, how do I did that? I've always just done 'make -k check' after > full bootstraps. > I assume the stage 1 artifacts are the ones in the prev-* directories. There's a --disable-bootstrap configure option. >> What distro are you using for native builds? The m68k debian I'm using >> does not have an installable gcc package. > > I run a bespoke distro on m68k and sparc64, derived from Fedora but > massively cut down in size, with target patches done by myself or > ported from Debian and Gentoo as necessary. > > Debian/m68k not having a gcc package? That sounds odd; I see e.g. a > gcc-9 in http://ftp.ports.debian.org/debian-ports/pool-m68k/main/g/ Turns out I wasn't sufficiently familiar with how debian works. I was missing an "apt update" step. I kind of assumed a package like gcc would install out of the box (others did, things like emacs). Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 20:50 ` Bernd Schmidt @ 2019-11-20 22:18 ` Richard Earnshaw 2019-11-21 12:32 ` Matthias Klose 0 siblings, 1 reply; 36+ messages in thread From: Richard Earnshaw @ 2019-11-20 22:18 UTC (permalink / raw) To: Bernd Schmidt, Mikael Pettersson; +Cc: Andreas Schwab, GCC Patches On 20/11/2019 20:48, Bernd Schmidt wrote: > On 11/20/19 8:27 PM, Mikael Pettersson wrote: >> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: >>> Probably best to just run tests on stage1 and hope something shows up. >> >> Ok, how do I did that? I've always just done 'make -k check' after >> full bootstraps. >> I assume the stage 1 artifacts are the ones in the prev-* directories. > > There's a --disable-bootstrap configure option. > >>> What distro are you using for native builds? The m68k debian I'm using >>> does not have an installable gcc package. >> >> I run a bespoke distro on m68k and sparc64, derived from Fedora but >> massively cut down in size, with target patches done by myself or >> ported from Debian and Gentoo as necessary. >> >> Debian/m68k not having a gcc package? That sounds odd; I see e.g. a >> gcc-9 in http://ftp.ports.debian.org/debian-ports/pool-m68k/main/g/ > > Turns out I wasn't sufficiently familiar with how debian works. I was > missing an "apt update" step. I kind of assumed a package like gcc would > install out of the box (others did, things like emacs). > > > Bernd > If you're building gcc on debian/ubuntu you probably also want apt build-dep gcc to install all the packages needed for building the compiler. R. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-20 22:18 ` Richard Earnshaw @ 2019-11-21 12:32 ` Matthias Klose 2019-11-21 14:02 ` Bernd Schmidt 0 siblings, 1 reply; 36+ messages in thread From: Matthias Klose @ 2019-11-21 12:32 UTC (permalink / raw) To: Richard Earnshaw, Bernd Schmidt, Mikael Pettersson Cc: Andreas Schwab, GCC Patches On 20.11.19 22:38, Richard Earnshaw wrote: > On 20/11/2019 20:48, Bernd Schmidt wrote: >> On 11/20/19 8:27 PM, Mikael Pettersson wrote: >>> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt <bernds_cb1@t-online.de> wrote: >>>> Probably best to just run tests on stage1 and hope something shows up. >>> >>> Ok, how do I did that? I've always just done 'make -k check' after >>> full bootstraps. >>> I assume the stage 1 artifacts are the ones in the prev-* directories. >> >> There's a --disable-bootstrap configure option. >> >>>> What distro are you using for native builds? The m68k debian I'm using >>>> does not have an installable gcc package. >>> >>> I run a bespoke distro on m68k and sparc64, derived from Fedora but >>> massively cut down in size, with target patches done by myself or >>> ported from Debian and Gentoo as necessary. >>> >>> Debian/m68k not having a gcc package? That sounds odd; I see e.g. a >>> gcc-9 in http://ftp.ports.debian.org/debian-ports/pool-m68k/main/g/ >> >> Turns out I wasn't sufficiently familiar with how debian works. I was >> missing an "apt update" step. I kind of assumed a package like gcc would >> install out of the box (others did, things like emacs). >> >> >> Bernd >> > > If you're building gcc on debian/ubuntu you probably also want > > apt build-dep gcc > > to install all the packages needed for building the compiler. that would be apt build-dep gcc-9. The former would only install the build dependencies of the gcc-defaults package. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-21 12:32 ` Matthias Klose @ 2019-11-21 14:02 ` Bernd Schmidt 0 siblings, 0 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-21 14:02 UTC (permalink / raw) To: Matthias Klose, Richard Earnshaw, Mikael Pettersson Cc: Andreas Schwab, GCC Patches On 11/21/19 1:30 PM, Matthias Klose wrote: > > that would be apt build-dep gcc-9. The former would only install the build > dependencies of the gcc-defaults package. That gets me E: You must put some 'source' URIs in your sources.list where /etc/apt/sources.list looks like deb http://ftp.ports.debian.org/debian-ports sid main deb-src http://ftp.ports.debian.org/debian-ports sid main which googling suggests is what I want? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-17 16:19 [PATCH 0/4] Eliminate cc0 from m68k Mikael Pettersson 2019-11-17 16:58 ` Andreas Schwab @ 2019-11-21 14:36 ` John Paul Adrian Glaubitz 1 sibling, 0 replies; 36+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-21 14:36 UTC (permalink / raw) To: Bernd Schmidt, 8736em8mp7.fsf, CAM43=SM3sAYrchnFUAEMhJCVQDe5+XXk4AooPSAHJ5XzN4hhhQ, 962cf853-0809-f6ea-fbf7-48ac161e0cc6, CAM43=SNYtxVSQ0p8+xLtF7Xt4YC72u6fC=uVhaKWdhsJ3sVeTA, CAM43=SNYTYPC0b0igOLKCzopRNAsbhMvBywg=E2bYiY1MuUf=Q, b2907cb5-7ec9-a084-bb9f-08eafbbcd201, CAM43=SOGB6kf3=ChOrPGbc3mUSDkrRG0Fnq4-KtrgWASm+78jg, cb301ecc-fa10-bc73-92a9-dbb02a959032, 21a75622-4af0-6f70-875e-60920af5e073, 5a6841a0-fe62-da5e-13be-4bf324e4057f Cc: Matthias Klose, Richard Earnshaw, Mikael Pettersson, Andreas Schwab, gcc-patches Hi Bernd! This should work: # binary default deb http://ftp.ports.debian.org/debian-ports/ unstable main deb http://incoming.ports.debian.org/buildd/ unstable main deb http://ftp.ports.debian.org/debian-ports/ unreleased main # source deb-src http://ftp.debian.org/debian/ unstable main deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main The two lines starting with incoming are optional. They will just help getting newly built packages faster. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 0/4] Eliminate cc0 from m68k @ 2019-11-13 13:08 Bernd Schmidt 2019-11-13 18:58 ` Segher Boessenkool ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-13 13:08 UTC (permalink / raw) To: GCC Patches This is a set of patches to convert m68k so that it no longer uses cc0. The approach is to combine cc0 setter/user pairs into cbranch and cstore patterns. It does not expose the flag register directly. Since m68k is a target that is not under active development, and probably receives very limited testing, I felt it was important to make it generate as close to the same code as previously. Also, given that the target clobbers the flags for pretty much every move, it seems unlikely that there's much value to be had from anything more complex. Trying to model every instruction's effect on the flags would be too error-prone for not nearly enough gain. The cc0 machinery allows for eliminating unnecessary comparisons by examining the effect instructions have on the flags registers. I have replicated that mechanism with a relatively modest amount of code based on a final_postscan_insn hook, but it is now opt-in: an instruction pattern can set the "flags_valid" attribute to a number of possible values to indicate what effect it has. That should be more reliable (try git log m68k.md to see recent sprinkling of CC_STATUS_INIT to squash bugs with the previous mechanism). We can remember either values where the flags indicate a comparison against zero (after practically all arithmetic and move insns), or alternatively record two comparison operands to eliminate identical compares. I stopped adding optimizations once I found it hard to find any meaningful differences in generated code. In particular, the m68k.exp tests which verify that these optimizations are performed all still pass. Testing was done with the qemu-system-m68k/debian combination. I do not have access to Coldfire hardware, and I tried to be somewhat conservative, for example by not adding "flags_valid" everywhere it would probably be possible. For someone with access to the hardware, it should be trivial to add such attributes and test that everything still works. I'll have to rerun my final tests because test_summary made a mess of things, but as far as I am able to tell, there are no regressions, and the patch set even fixes some failures in libstdc++. The first and second patch contain the m68k changes. They are separated only to make the review easier, they were not tested separately (since the time for a test run is measured in days). The first patch contains preliminary cleanup and fixes, the second the main cc0 conversion. After that, there are some changes in the rest of the compiler. Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 13:08 Bernd Schmidt @ 2019-11-13 18:58 ` Segher Boessenkool 2019-11-13 19:07 ` Bernd Schmidt 2019-11-13 19:41 ` Jeff Law 2019-11-15 13:49 ` Andreas Schwab 2 siblings, 1 reply; 36+ messages in thread From: Segher Boessenkool @ 2019-11-13 18:58 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Wed, Nov 13, 2019 at 02:04:59PM +0100, Bernd Schmidt wrote: > This is a set of patches to convert m68k so that it no longer uses cc0. I tried this out with a kernel build (just the defconfig). First problem was patch 4 doesn't apply, it has white-space damage. It's small, I fixed that up manually. But then I hit during RTL pass: jump2 /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump': /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1290 0x102c3c2f patch_jump_insn /home/segher/src/gcc/gcc/cfgrtl.c:1290 0x102c3df3 redirect_branch_edge /home/segher/src/gcc/gcc/cfgrtl.c:1317 0x102c442b rtl_redirect_edge_and_branch /home/segher/src/gcc/gcc/cfgrtl.c:1450 0x102ad04f redirect_edge_and_branch(edge_def*, basic_block_def*) /home/segher/src/gcc/gcc/cfghooks.c:373 0x10dbb517 try_forward_edges /home/segher/src/gcc/gcc/cfgcleanup.c:562 0x10dbb517 try_optimize_cfg /home/segher/src/gcc/gcc/cfgcleanup.c:2960 0x10dbb517 cleanup_cfg(int) /home/segher/src/gcc/gcc/cfgcleanup.c:3174 0x10dbd41f execute /home/segher/src/gcc/gcc/cfgcleanup.c:3353 Can you reproduce that? Segher ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 18:58 ` Segher Boessenkool @ 2019-11-13 19:07 ` Bernd Schmidt 2019-11-13 19:25 ` Segher Boessenkool 2019-11-15 13:48 ` John Paul Adrian Glaubitz 0 siblings, 2 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-13 19:07 UTC (permalink / raw) To: Segher Boessenkool; +Cc: GCC Patches [-- Attachment #1: Type: text/plain, Size: 855 bytes --] On 11/13/19 7:16 PM, Segher Boessenkool wrote: > I tried this out with a kernel build (just the defconfig). > during RTL pass: jump2 > /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump': > /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1290 > Can you reproduce that? Yes. It's actually an issue I spotted at one point, but I thought to myself "I'll just leave it, I want to make the minimum amount of changes". Should have thought harder. The constraints for comparison patterns in m68k.md allow constants as the first operand of a comparison. They also use nonimmediate_operand. Hence, the internal error you saw when something tries to rerecognize the instruction. The following should fix it, but it's only very lightly tested so far. I'll merge it into patch 2. Bernd [-- Attachment #2: m68k-5.diff --] [-- Type: text/x-patch, Size: 781 bytes --] * config/m68k/m68k.md (cmp1_constraints): Don't allow constants. diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md index bb46e5880e2..56685db0c72 100644 --- a/gcc/config/m68k/m68k.md +++ b/gcc/config/m68k/m68k.md @@ -488,7 +488,7 @@ ;; and operand predicates. So to be safe, just don't allow the PC-rel (define_mode_attr scc0_constraints [(QI "=d,d,d") (HI "=d,d,d,d,d") (SI "=d,d,d,d,d,d")]) -(define_mode_attr cmp1_constraints [(QI "dn,dm,>") (HI "rnm,d,n,m,>") (SI "r,rKT,rKs,mr,ma,>")]) +(define_mode_attr cmp1_constraints [(QI "dn,dm,>") (HI "rnm,d,n,m,>") (SI "r,r,r,mr,ma,>")]) (define_mode_attr cmp2_constraints [(QI "dm,nd,>") (HI "d,rnm,m,n,>") (SI "mrC0,mr,ma,KTrC0,Ksr,>")]) ;; Note that operand 0 of an SCC insn is supported in the hardware as ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 19:07 ` Bernd Schmidt @ 2019-11-13 19:25 ` Segher Boessenkool 2019-11-15 13:48 ` John Paul Adrian Glaubitz 1 sibling, 0 replies; 36+ messages in thread From: Segher Boessenkool @ 2019-11-13 19:25 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Wed, Nov 13, 2019 at 07:57:58PM +0100, Bernd Schmidt wrote: > On 11/13/19 7:16 PM, Segher Boessenkool wrote: > > I tried this out with a kernel build (just the defconfig). > > > during RTL pass: jump2 > > /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump': > > /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in patch_jump_insn, at cfgrtl.c:1290 > > > Can you reproduce that? > > Yes. It's actually an issue I spotted at one point, but I thought to > myself "I'll just leave it, I want to make the minimum amount of > changes". Should have thought harder. > > The constraints for comparison patterns in m68k.md allow constants as > the first operand of a comparison. They also use nonimmediate_operand. > Hence, the internal error you saw when something tries to rerecognize > the instruction. > > The following should fix it, but it's only very lightly tested so far. > I'll merge it into patch 2. It works on the kernel build, at least. No idea if this *runs*, I just built it ;-) Sizes, R0 is trunk, R1 is with your patches: R0 R1 m68k 3720557 3721245 (that is 100.018%, looks great!) Segher ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 19:07 ` Bernd Schmidt 2019-11-13 19:25 ` Segher Boessenkool @ 2019-11-15 13:48 ` John Paul Adrian Glaubitz 2019-11-15 14:36 ` John Paul Adrian Glaubitz 1 sibling, 1 reply; 36+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-15 13:48 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Bernd Schmidt, gcc-patches Hi Segher! > It works on the kernel build, at least. No idea if this *runs*, I just > built it ;-) I just did that and kernel 5.3.9 built with gcc trunk with Bernd's patches boots fine on qemu-m68k-system. I will test the kernel on a real Amiga later but I'm confident it will work there as well. Thanks to everyone, especially Bernd for helping to make the cc0 transition for m68k happen! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 13:48 ` John Paul Adrian Glaubitz @ 2019-11-15 14:36 ` John Paul Adrian Glaubitz 0 siblings, 0 replies; 36+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-15 14:36 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Bernd Schmidt, gcc-patches Hi! On 11/15/19 2:45 PM, John Paul Adrian Glaubitz wrote: >> It works on the kernel build, at least. No idea if this *runs*, I just >> built it ;-) > > I just did that and kernel 5.3.9 built with gcc trunk with Bernd's patches > boots fine on qemu-m68k-system. I will test the kernel on a real Amiga > later but I'm confident it will work there as well. Kernel built with the patched gcc-10 also boots fine on my Amiga 4000 68060 :). I'm test building various packages now to see if I can see any other issues but so far I'm very confident that there are no obvious regressions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 13:08 Bernd Schmidt 2019-11-13 18:58 ` Segher Boessenkool @ 2019-11-13 19:41 ` Jeff Law 2019-11-14 15:00 ` Richard Henderson 2019-11-15 13:49 ` Andreas Schwab 2 siblings, 1 reply; 36+ messages in thread From: Jeff Law @ 2019-11-13 19:41 UTC (permalink / raw) To: Bernd Schmidt, GCC Patches On 11/13/19 6:04 AM, Bernd Schmidt wrote: > This is a set of patches to convert m68k so that it no longer uses cc0. > The approach is to combine cc0 setter/user pairs into cbranch and cstore > patterns. It does not expose the flag register directly. Since m68k is a > target that is not under active development, and probably receives very > limited testing, I felt it was important to make it generate as close to > the same code as previously. Also, given that the target clobbers the > flags for pretty much every move, it seems unlikely that there's much > value to be had from anything more complex. Trying to model every > instruction's effect on the flags would be too error-prone for not > nearly enough gain. I tend to agree. My only worry would be introducing a new way to deal with cc0. But I'll certainly look at the changes with an open mind. It might play well with ideas I had while looking at the H8 port which has a very similar model. > > The cc0 machinery allows for eliminating unnecessary comparisons by > examining the effect instructions have on the flags registers. I have > replicated that mechanism with a relatively modest amount of code based > on a final_postscan_insn hook, but it is now opt-in: an instruction > pattern can set the "flags_valid" attribute to a number of possible > values to indicate what effect it has. That should be more reliable (try > git log m68k.md to see recent sprinkling of CC_STATUS_INIT to squash > bugs with the previous mechanism). Yea, sounds like a reimplementation of the tst elimination bits, but buried in the backend. Given the choice of dropping the port or burying this kind of stuff in there, I'd lean towards accepting the latter. > We can remember either values where the flags indicate a comparison > against zero (after practically all arithmetic and move insns), or > alternatively record two comparison operands to eliminate identical > compares. I stopped adding optimizations once I found it hard to find > any meaningful differences in generated code. In particular, the > m68k.exp tests which verify that these optimizations are performed all > still pass. Yea. One of the things I was pondering was dropping many/most of the combiner patterns then only adding those back which were clearly still important. I have a strong suspicion we have *many* unnecessary patterns. Of course finding those may be more work than its worth. > > Testing was done with the qemu-system-m68k/debian combination. I do not > have access to Coldfire hardware, and I tried to be somewhat > conservative, for example by not adding "flags_valid" everywhere it > would probably be possible. For someone with access to the hardware, it > should be trivial to add such attributes and test that everything still > works. I'm happy to add your patch to my tester. It'll verify the compiler bootstraps and can build glibc & the kernel. Jeff ps. On a more personal note -- good to hear from you Bernd. I hope things are going well. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 19:41 ` Jeff Law @ 2019-11-14 15:00 ` Richard Henderson 0 siblings, 0 replies; 36+ messages in thread From: Richard Henderson @ 2019-11-14 15:00 UTC (permalink / raw) To: Jeff Law, Bernd Schmidt, GCC Patches On 11/13/19 8:35 PM, Jeff Law wrote: > On 11/13/19 6:04 AM, Bernd Schmidt wrote: >> The cc0 machinery allows for eliminating unnecessary comparisons by >> examining the effect instructions have on the flags registers. I have >> replicated that mechanism with a relatively modest amount of code based >> on a final_postscan_insn hook, but it is now opt-in: an instruction >> pattern can set the "flags_valid" attribute to a number of possible >> values to indicate what effect it has. That should be more reliable (try >> git log m68k.md to see recent sprinkling of CC_STATUS_INIT to squash >> bugs with the previous mechanism). > Yea, sounds like a reimplementation of the tst elimination bits, but > buried in the backend. Given the choice of dropping the port or burying > this kind of stuff in there, I'd lean towards accepting the latter. Indeed. Even if we wanted an eventual transition to the tst elimination bits, this is a better starting place than from cc0. r~ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-13 13:08 Bernd Schmidt 2019-11-13 18:58 ` Segher Boessenkool 2019-11-13 19:41 ` Jeff Law @ 2019-11-15 13:49 ` Andreas Schwab 2019-11-15 16:34 ` Bernd Schmidt 2 siblings, 1 reply; 36+ messages in thread From: Andreas Schwab @ 2019-11-15 13:49 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches Here are the results of running the testsuite on m68k-linux: http://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00908.html This is a list of regressions: g++.old-deja/g++.other/dyncast1.C -std=c++14 execution test g++.old-deja/g++.other/dyncast1.C -std=c++17 execution test g++.old-deja/g++.other/dyncast1.C -std=c++2a execution test g++.old-deja/g++.other/dyncast1.C -std=c++98 execution test g++.old-deja/g++.other/dyncast6.C -std=gnu++14 execution test g++.old-deja/g++.other/dyncast6.C -std=gnu++17 execution test g++.old-deja/g++.other/dyncast6.C -std=gnu++2a execution test g++.old-deja/g++.other/dyncast6.C -std=gnu++98 execution test g++.old-deja/g++.other/rttid3.C -std=gnu++14 execution test g++.old-deja/g++.other/rttid3.C -std=gnu++17 execution test g++.old-deja/g++.other/rttid3.C -std=gnu++2a execution test g++.old-deja/g++.other/rttid3.C -std=gnu++98 execution test g++.old-deja/g++.robertl/eb46.C -std=c++14 execution test g++.old-deja/g++.robertl/eb46.C -std=c++17 execution test g++.old-deja/g++.robertl/eb46.C -std=c++2a execution test g++.old-deja/g++.robertl/eb46.C -std=c++98 execution test 18_support/nested_exception/rethrow_if_nested.cc execution test 20_util/function_objects/comparisons_pointer.cc execution test 21_strings/basic_string/inserters_extractors/char/8.cc execution test 22_locale/num_get/get/char/16.cc execution test 24_iterators/istream_iterator/1.cc execution test 25_algorithms/copy_n/50119.cc execution test 27_io/basic_istream/extractors_arithmetic/char/01.cc execution test 27_io/basic_istream/extractors_arithmetic/char/02.cc execution test 27_io/basic_istream/extractors_arithmetic/char/03.cc execution test 27_io/basic_istream/extractors_arithmetic/char/10.cc execution test 27_io/basic_istream/extractors_arithmetic/char/11.cc execution test 27_io/basic_istream/extractors_arithmetic/char/13.cc execution test 27_io/basic_istream/extractors_arithmetic/char/dr696.cc execution test 27_io/basic_istream/seekg/char/8348-1.cc execution test 27_io/basic_istream/seekg/char/8348-2.cc execution test 27_io/basic_istream/tellg/char/8348.cc execution test 27_io/basic_istringstream/assign/1.cc execution test 27_io/basic_istringstream/cons/move.cc execution test 27_io/basic_istringstream/str/char/1.cc execution test 27_io/basic_stringbuf/seekoff/char/1.cc execution test 27_io/basic_stringbuf/seekoff/wchar_t/1.cc execution test 27_io/basic_stringbuf/seekoff/wchar_t/2.cc execution test 27_io/basic_stringstream/assign/1.cc execution test 27_io/filesystem/path/concat/path.cc execution test 27_io/manipulators/standard/char/quoted.cc execution test 27_io/rvalue_streams.cc execution test 28_regex/algorithms/regex_match/awk/cstring_01.cc execution test 28_regex/algorithms/regex_match/ecma/char/57173.cc execution test 28_regex/algorithms/regex_match/ecma/char/68863.cc execution test 28_regex/algorithms/regex_match/ecma/char/backref.cc execution test 28_regex/algorithms/regex_match/ecma/char/emptygroup.cc execution test 28_regex/algorithms/regex_match/ecma/char/hex.cc execution test 28_regex/algorithms/regex_match/extended/cstring_range.cc execution test 28_regex/algorithms/regex_replace/char/basic_replace.cc execution test 28_regex/algorithms/regex_replace/char/dr2213.cc execution test 28_regex/basic_regex/multiple_quantifiers.cc execution test 28_regex/match_results/format.cc execution test 28_regex/regression.cc execution test 28_regex/traits/char/value.cc execution test backward/strstream_move.cc execution test ext/random/k_distribution/operators/serialize.cc execution test ext/random/nakagami_distribution/operators/serialize.cc execution test ext/random/normal_mv_distribution/operators/serialize.cc execution test ext/random/rice_distribution/operators/serialize.cc execution test ext/random/uniform_inside_sphere_distribution/operators/serialize.cc execution test tr1/5_numerical_facilities/random/discard_block/operators/serialize.cc execution test tr1/7_regular_expressions/regex_traits/char/value.cc execution test tr1/7_regular_expressions/regex_traits/wchar_t/value.cc execution test Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 13:49 ` Andreas Schwab @ 2019-11-15 16:34 ` Bernd Schmidt 2019-11-15 16:36 ` Andreas Schwab 0 siblings, 1 reply; 36+ messages in thread From: Bernd Schmidt @ 2019-11-15 16:34 UTC (permalink / raw) To: Andreas Schwab; +Cc: GCC Patches On 11/15/19 2:48 PM, Andreas Schwab wrote: > Here are the results of running the testsuite on m68k-linux: > > http://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00908.html > > This is a list of regressions: Are these with the patch? I'm not seeing any of these in my testing with qemu. Are you on real hardware (and on which hardware?), and can you do anything to help narrow down what's going wrong? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 16:34 ` Bernd Schmidt @ 2019-11-15 16:36 ` Andreas Schwab 2019-11-15 21:41 ` Bernd Schmidt 0 siblings, 1 reply; 36+ messages in thread From: Andreas Schwab @ 2019-11-15 16:36 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Nov 15 2019, Bernd Schmidt wrote: > Are these with the patch? Yes. > Are you on real hardware No, I'm using aranym. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 16:36 ` Andreas Schwab @ 2019-11-15 21:41 ` Bernd Schmidt 2019-11-15 22:21 ` Andreas Schwab 0 siblings, 1 reply; 36+ messages in thread From: Bernd Schmidt @ 2019-11-15 21:41 UTC (permalink / raw) To: Andreas Schwab; +Cc: GCC Patches On 11/15/19 5:34 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> Are these with the patch? > > Yes. > >> Are you on real hardware > > No, I'm using aranym. Any chance you could show the command lines from the log files or some other way of reproducing the issue? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 21:41 ` Bernd Schmidt @ 2019-11-15 22:21 ` Andreas Schwab 2019-11-15 22:22 ` Bernd Schmidt 0 siblings, 1 reply; 36+ messages in thread From: Andreas Schwab @ 2019-11-15 22:21 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Nov 15 2019, Bernd Schmidt wrote: > Any chance you could show the command lines from the log files or some > other way of reproducing the issue? Executing on aranym: OMP_NUM_THREADS=2 LD_LIBRARY_PATH=.:/daten/aranym/gcc/gcc-20191115/Build/m68k-linux/./libstdc++-v3/src/.libs:/daten/aranym/gcc/gcc-20191115/Build/m68k-linux/./libstdc++-v3/src/.libs:/daten/aranym/gcc/gcc-20191115/Build/gcc:/daten/aranym/gcc/gcc-20191115/Build/gcc timeout 1200 ./dyncast1.exe (timeout = 300) Executed ./dyncast1.exe, status 1 Output: Error 25 child process exited abnormally FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++17 execution test Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 22:21 ` Andreas Schwab @ 2019-11-15 22:22 ` Bernd Schmidt 2019-11-15 22:57 ` Andreas Schwab 0 siblings, 1 reply; 36+ messages in thread From: Bernd Schmidt @ 2019-11-15 22:22 UTC (permalink / raw) To: Andreas Schwab; +Cc: GCC Patches On 11/15/19 10:58 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> Any chance you could show the command lines from the log files or some >> other way of reproducing the issue? > > Executing on aranym: OMP_NUM_THREADS=2 LD_LIBRARY_PATH=.:/daten/aranym/gcc/gcc-20191115/Build/m68k-linux/./libstdc++-v3/src/.libs:/daten/aranym/gcc/gcc-20191115/Build/m68k-linux/./libstdc++-v3/src/.libs:/daten/aranym/gcc/gcc-20191115/Build/gcc:/daten/aranym/gcc/gcc-20191115/Build/gcc timeout 1200 ./dyncast1.exe (timeout = 300) > Executed ./dyncast1.exe, status 1 > Output: Error 25 > child process exited abnormally > FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++17 execution test I meant the compiler command line of course... for any -mcpu flags that might differ from my test run. Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 22:22 ` Bernd Schmidt @ 2019-11-15 22:57 ` Andreas Schwab 2019-11-16 0:17 ` Bernd Schmidt 2019-11-16 12:16 ` John Paul Adrian Glaubitz 0 siblings, 2 replies; 36+ messages in thread From: Andreas Schwab @ 2019-11-15 22:57 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Nov 15 2019, Bernd Schmidt wrote: > I meant the compiler command line of course... for any -mcpu flags that > might differ from my test run. There are none. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 22:57 ` Andreas Schwab @ 2019-11-16 0:17 ` Bernd Schmidt 2019-11-16 8:26 ` Andreas Schwab 2019-11-16 10:47 ` Andreas Schwab 2019-11-16 12:16 ` John Paul Adrian Glaubitz 1 sibling, 2 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-16 0:17 UTC (permalink / raw) To: Andreas Schwab; +Cc: GCC Patches On 11/15/19 11:50 PM, Andreas Schwab wrote: > On Nov 15 2019, Bernd Schmidt wrote: > >> I meant the compiler command line of course... for any -mcpu flags that >> might differ from my test run. > > There are none. Well, there has to be some difference between what you are doing and what I am doing, because: Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ... === g++ Summary === # of expected passes 26826 # of expected failures 82 # of unsupported tests 157 /local/src/egcs/bm68k-test/gcc/xg++ version 10.0.0 20191101 (experimental) (GCC) Is there anything you think you can give me to help reproduce this? Before/after assembly files, generated with -fverbose-asm? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-16 0:17 ` Bernd Schmidt @ 2019-11-16 8:26 ` Andreas Schwab 2019-11-16 13:32 ` Bernd Schmidt 2019-11-16 10:47 ` Andreas Schwab 1 sibling, 1 reply; 36+ messages in thread From: Andreas Schwab @ 2019-11-16 8:26 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches On Nov 16 2019, Bernd Schmidt wrote: > Well, there has to be some difference between what you are doing and > what I am doing, because: > > Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ... > > === g++ Summary === > > # of expected passes 26826 > # of expected failures 82 > # of unsupported tests 157 > /local/src/egcs/bm68k-test/gcc/xg++ version 10.0.0 20191101 > (experimental) (GCC) === g++ Summary === # of expected passes 170041 # of unexpected failures 74 # of expected failures 708 # of unresolved testcases 2 # of unsupported tests 7419 /daten/aranym/gcc/gcc-20191115/Build/gcc/xg++ version 10.0.0 20191114 (experimental) [trunk revision 278266] (GCC) Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-16 8:26 ` Andreas Schwab @ 2019-11-16 13:32 ` Bernd Schmidt 0 siblings, 0 replies; 36+ messages in thread From: Bernd Schmidt @ 2019-11-16 13:32 UTC (permalink / raw) To: Andreas Schwab; +Cc: GCC Patches On 11/16/19 9:18 AM, Andreas Schwab wrote: > On Nov 16 2019, Bernd Schmidt wrote: > >> Well, there has to be some difference between what you are doing and >> what I am doing, because: >> >> Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ... >> >> === g++ Summary === >> >> # of expected passes 26826 >> # of expected failures 82 >> # of unsupported tests 157 >> /local/src/egcs/bm68k-test/gcc/xg++ version 10.0.0 20191101 >> (experimental) (GCC) > > === g++ Summary === > > # of expected passes 170041 > # of unexpected failures 74 > # of expected failures 708 > # of unresolved testcases 2 > # of unsupported tests 7419 > /daten/aranym/gcc/gcc-20191115/Build/gcc/xg++ version 10.0.0 20191114 (experimental) [trunk revision 278266] (GCC) Once again, that doesn't help me track things down. A bug report without instructions to reproduce is useless. Could you please provide me the generated assembly files with -fverbose-asm that I asked for? Bernd ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-16 0:17 ` Bernd Schmidt 2019-11-16 8:26 ` Andreas Schwab @ 2019-11-16 10:47 ` Andreas Schwab 1 sibling, 0 replies; 36+ messages in thread From: Andreas Schwab @ 2019-11-16 10:47 UTC (permalink / raw) To: Bernd Schmidt; +Cc: GCC Patches Running /daten/aranym/gcc/gcc-20191116/gcc/testsuite/g++.old-deja/old-deja.exp ... FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++98 execution test FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++14 execution test FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++17 execution test FAIL: g++.old-deja/g++.other/dyncast1.C -std=c++2a execution test FAIL: g++.old-deja/g++.other/dyncast6.C -std=gnu++98 execution test FAIL: g++.old-deja/g++.other/dyncast6.C -std=gnu++14 execution test FAIL: g++.old-deja/g++.other/dyncast6.C -std=gnu++17 execution test FAIL: g++.old-deja/g++.other/dyncast6.C -std=gnu++2a execution test FAIL: g++.old-deja/g++.other/rttid3.C -std=gnu++98 execution test FAIL: g++.old-deja/g++.other/rttid3.C -std=gnu++14 execution test FAIL: g++.old-deja/g++.other/rttid3.C -std=gnu++17 execution test FAIL: g++.old-deja/g++.other/rttid3.C -std=gnu++2a execution test FAIL: g++.old-deja/g++.robertl/eb46.C -std=c++98 execution test FAIL: g++.old-deja/g++.robertl/eb46.C -std=c++14 execution test FAIL: g++.old-deja/g++.robertl/eb46.C -std=c++17 execution test FAIL: g++.old-deja/g++.robertl/eb46.C -std=c++2a execution test === g++ Summary === # of expected passes 26803 # of unexpected failures 16 # of expected failures 82 # of unsupported tests 157 /daten/aranym/gcc/gcc-20191116/Build/gcc/xg++ version 10.0.0 20191115 (experimental) [trunk revision 278320] (GCC) Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 0/4] Eliminate cc0 from m68k 2019-11-15 22:57 ` Andreas Schwab 2019-11-16 0:17 ` Bernd Schmidt @ 2019-11-16 12:16 ` John Paul Adrian Glaubitz 1 sibling, 0 replies; 36+ messages in thread From: John Paul Adrian Glaubitz @ 2019-11-16 12:16 UTC (permalink / raw) To: Andreas Schwab, d6a42db5-cc76-95b7-abe4-2487ff06e5aa Cc: Bernd Schmidt, gcc-patches Hi Andreas! > === g++ Summary === > > # of expected passes 26803 > # of unexpected failures 16 > # of expected failures 82 > # of unsupported tests 157 > /daten/aranym/gcc/gcc-20191116/Build/gcc/xg++ version 10.0.0 20191115 (experimental) [trunk revision 278320] (GCC) Is this testsuite run with or without Bernd's patches? If yes, I think it would be a good sign that the patches are good for submission. I will try to get the patches backported to gcc-9 so that we can start building Debian packages with a patched gcc-9 which may help finding more regressions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2019-11-21 14:34 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-17 16:19 [PATCH 0/4] Eliminate cc0 from m68k Mikael Pettersson 2019-11-17 16:58 ` Andreas Schwab 2019-11-17 18:04 ` Jeff Law 2019-11-17 19:45 ` Mikael Pettersson 2019-11-18 19:39 ` Bernd Schmidt 2019-11-18 20:57 ` Mikael Pettersson 2019-11-20 13:52 ` Mikael Pettersson 2019-11-20 14:29 ` Bernd Schmidt 2019-11-20 16:59 ` Jeff Law 2019-11-20 20:04 ` Mikael Pettersson 2019-11-20 20:29 ` Jeff Law 2019-11-20 20:50 ` Bernd Schmidt 2019-11-20 22:18 ` Richard Earnshaw 2019-11-21 12:32 ` Matthias Klose 2019-11-21 14:02 ` Bernd Schmidt 2019-11-21 14:36 ` John Paul Adrian Glaubitz -- strict thread matches above, loose matches on Subject: below -- 2019-11-13 13:08 Bernd Schmidt 2019-11-13 18:58 ` Segher Boessenkool 2019-11-13 19:07 ` Bernd Schmidt 2019-11-13 19:25 ` Segher Boessenkool 2019-11-15 13:48 ` John Paul Adrian Glaubitz 2019-11-15 14:36 ` John Paul Adrian Glaubitz 2019-11-13 19:41 ` Jeff Law 2019-11-14 15:00 ` Richard Henderson 2019-11-15 13:49 ` Andreas Schwab 2019-11-15 16:34 ` Bernd Schmidt 2019-11-15 16:36 ` Andreas Schwab 2019-11-15 21:41 ` Bernd Schmidt 2019-11-15 22:21 ` Andreas Schwab 2019-11-15 22:22 ` Bernd Schmidt 2019-11-15 22:57 ` Andreas Schwab 2019-11-16 0:17 ` Bernd Schmidt 2019-11-16 8:26 ` Andreas Schwab 2019-11-16 13:32 ` Bernd Schmidt 2019-11-16 10:47 ` Andreas Schwab 2019-11-16 12:16 ` John Paul Adrian Glaubitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).