Re: [PATCH 0/4] Eliminate cc0 from m68k

[John Paul Adrian Glaubitz]

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Matthias Klose]

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  
>>> 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.

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Richard Earnshaw]

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  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.

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

On 11/20/19 8:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt  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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Jeff Law]

On 11/20/19 12:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt
>  wrote:
>> 
>> On 11/20/19 2:50 PM, Mikael Pettersson wrote:
>>> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
>>>  wrote:
 
 On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt
  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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Mikael Pettersson]

On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt  wrote:
>
> On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> > On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson  
> > wrote:
> >>
> >> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt  
> >> 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/

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Jeff Law]

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  
>> wrote:
>>>
>>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt  
>>> 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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson  
> wrote:
>>
>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt  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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Mikael Pettersson]

On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson  wrote:
>
> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt  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 [0xfff4])))
(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  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.

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Mikael Pettersson]

On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt  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.

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Mikael Pettersson]

On Sun, Nov 17, 2019 at 5:57 PM 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_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 "" 
> "")
>(match_operand:SI 3 "const_int_operand" "n")
>
> Andreas.

This fixed the problem, thanks.

/Mikael

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Jeff Law]

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_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 "" 
> "")
>  (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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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_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 "" 
"")
   (match_operand:SI 3 "const_int_operand" "n")

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Mikael Pettersson]

On Wed, 13 Nov 2019 14:04:59 +0100, Bernd Schmidt
 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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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 failures708
> # of unresolved testcases 2
> # of unsupported tests7419
> /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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[John Paul Adrian Glaubitz]

Hi Andreas!

> === g++ Summary ===
> 
> # of expected passes26803
> # of unexpected failures16
> # 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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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 passes26803
# of unexpected failures16
# 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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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 failures82
> # of unsupported tests157
> /local/src/egcs/bm68k-test/gcc/xg++  version 10.0.0 20191101
> (experimental) (GCC)

=== g++ Summary ===

# of expected passes170041
# of unexpected failures74
# 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, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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 passes26826
# 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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[John Paul Adrian Glaubitz]

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Andreas Schwab]

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, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 0/4] Eliminate cc0 from m68k

[John Paul Adrian Glaubitz]

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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Richard Henderson]

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~

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Jeff Law]

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.

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Segher Boessenkool]

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:

R0R1
m68k   3720557   3721245

(that is 100.018%, looks great!)


Segher

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Bernd Schmidt]

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
	* 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

Re: [PATCH 0/4] Eliminate cc0 from m68k

[Segher Boessenkool]

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