[PATCH 0/4] Eliminate cc0 from m68k

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

[PATCH 0/4] Eliminate cc0 from m68k

Bernd Schmidt
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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/4] Preliminary m68k patches

Bernd Schmidt
This tidies up a few spots in the m68k backend in preparation for the
large patch to follow.  This is purely for review purposes: this patch
has not been tested independently, and will be committed together with
the following one.

Noteworthy changes:

Some patterns and peepholes were unified through mode iterators.  The
m68k_subword_comparison_operator predicate was adapted to also work with
SImode.

There are already scc_di patterns, so there is no need to generate a cc0
set/use pair in cstoredi.

Without HAVE_cc0, combine sometimes substitutes a stack push into the
destination of a divmod instruction, and then gets confused because it
doesn't seem to expect it in a PARALLEL.  Since the instruction only
works on registers anyway, use register_operand.

There are patterns that use register_operand with "do" constraints which
allow memory. This works at reload time, but the instruction can not be
rerecognized later on.  This becomes a problem if such operands occur in
a jump instruction, as subsequent passes will try to redirect branches
and thus attempt to rerecognize the pattern.

movqi/movhi do not accept constants that are not CONST_INT.  The code to
output them would not set flags correctly and was changed to
gcc_unreachable.

Comments were added to some patterns which are not being generated due
to incorrect tests/predicates. Fixing these is out of scope for this
work, but the problems are at least documented.

All the passes working on conditional traps seem to assume
const_true_rtx is used for unconditional ones, rather than const1_rtx.


Bernd

m68k-1.diff (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/4] The main m68k cc0 conversion

Bernd Schmidt
In reply to this post by Bernd Schmidt
This achieves the conversion by using combined cbranch/cstore patterns,
and using a mechanism similar to the cc_status tracking to elide certain
comparisons.  Unlike cc_status, this is opt-in and requires a
flags_valid attribute to be set for suitable instructions.  Due to lack
of test hardware, this conversion is omitted for a number of coldfire
patterns as opposed to normal m68k.

For DImode comparisons, scc_di and beq0_di/bne0_di patterns already
existed and are reused.  The bgt0_di/ble0_di patterns are replaced with
expander code to test just the high word, along with some smarts in
m68k_find_flags_value.


Bernd
Reply | Threaded
Open this post in threaded view
|

[PATCH 3/4] Set costs for jumps in combine

Bernd Schmidt
In reply to this post by Bernd Schmidt
The combiner is somewhat strange about how it uses costs. If any of the
insns involved in a comparison have a cost of 0, it does not verify that
the substitution is cheaper. Also, it does not compute costs for jump
insns, so they are always set to zero. As a consequence, any possible
substitution is performed if a combination into a jump is possible,
which turns out isn't really desirable on m68k with cbranch patterns.

This patch simply removes a test for NONJUMP_INSN_P. Bootstrapped and
tested on the gcc135 machine (powerpc64le-unknown-linux-gnu).


Bernd

m68k-3.diff (628 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH 4/4] Fix autoinc cbranch

Bernd Schmidt
In reply to this post by Bernd Schmidt
After the m68k cc0 conversion, there is one code quality regression that
I can see: we no longer generate autoinc addressing modes in
comparisons. This is because the parts of the compiler that generate
autoinc are unwilling to substitute into jumps.

If you look at the code in reload, you'll see that it's careful around
jumps at find_reload time, and the code to perform autoinc reloads does
try to put all the extra code before the instruction. LRA seems to have
copied most of that code.
Also, in the former cc0 reality, a compare wasn't really any different
from a jump on m68k: we can't have a reload after the instruction in
either case. Any kind of move or arithmetic would clobber the flags.

That leads me to believe that there is no issue with autoinc in jumps,
hence this patch. Bootstrapped and tested on the gcc135 machine
(powerpc64le-unknown-linux-gnu). I don't really expect this to get
approved; alternatively I could write some peepholes which would
generate the same code as long as register pressure doesn't get too high.


Bernd

m68k-4.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/4] The main m68k cc0 conversion

Bernd Schmidt
In reply to this post by Bernd Schmidt
Once more with patch.


Bernd

m68k-2.diff (170K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 3/4] Set costs for jumps in combine

Segher Boessenkool
In reply to this post by Bernd Schmidt
Hi!

On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
> The combiner is somewhat strange about how it uses costs. If any of the
> insns involved in a comparison have a cost of 0, it does not verify that
> the substitution is cheaper.

"Cost 0" means "unknown cost".  This isn't just combine, it is a property
of insn_cost (and insn_rtx_cost before it).  It does make it impossible
for combine to deal with actual zero cost things.

> Also, it does not compute costs for jump
> insns, so they are always set to zero. As a consequence, any possible
> substitution is performed if a combination into a jump is possible,
> which turns out isn't really desirable on m68k with cbranch patterns.
>
> This patch simply removes a test for NONJUMP_INSN_P. Bootstrapped and
> tested on the gcc135 machine (powerpc64le-unknown-linux-gnu).

I wonder why that test was there.  It was added in r84513, which is where
insn_rtx_cost was made from combine_insn_cost, which didn't have that
non-jump thing yet.

It is still stage 1, so we'll find out if any target breaks I guess.
Okay for trunk.  Thanks!


Segher
Reply | Threaded
Open this post in threaded view
|

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

Segher Boessenkool
In reply to this post by Bernd Schmidt
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
Reply | Threaded
Open this post in threaded view
|

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

m68k-5.diff (796 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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:

                    R0        R1
        m68k   3720557   3721245

(that is 100.018%, looks great!)


Segher
Reply | Threaded
Open this post in threaded view
|

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

Jeff Law
In reply to this post by Bernd Schmidt
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.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/4] Preliminary m68k patches

Jeff Law
In reply to this post by Bernd Schmidt
On 11/13/19 6:08 AM, Bernd Schmidt wrote:

> This tidies up a few spots in the m68k backend in preparation for the
> large patch to follow.  This is purely for review purposes: this patch
> has not been tested independently, and will be committed together with
> the following one.
>
> Noteworthy changes:
>
> Some patterns and peepholes were unified through mode iterators.  The
> m68k_subword_comparison_operator predicate was adapted to also work with
> SImode.
>
> There are already scc_di patterns, so there is no need to generate a cc0
> set/use pair in cstoredi.
>
> Without HAVE_cc0, combine sometimes substitutes a stack push into the
> destination of a divmod instruction, and then gets confused because it
> doesn't seem to expect it in a PARALLEL.  Since the instruction only
> works on registers anyway, use register_operand.
>
> There are patterns that use register_operand with "do" constraints which
> allow memory. This works at reload time, but the instruction can not be
> rerecognized later on.  This becomes a problem if such operands occur in
> a jump instruction, as subsequent passes will try to redirect branches
> and thus attempt to rerecognize the pattern.
>
> movqi/movhi do not accept constants that are not CONST_INT.  The code to
> output them would not set flags correctly and was changed to
> gcc_unreachable.
>
> Comments were added to some patterns which are not being generated due
> to incorrect tests/predicates. Fixing these is out of scope for this
> work, but the problems are at least documented.
>
> All the passes working on conditional traps seem to assume
> const_true_rtx is used for unconditional ones, rather than const1_rtx.
>
>
> Bernd
>
>
> m68k-1.diff
>
>             * config/m68k/m68k.c (output_move_himode, output_move_qimode):
>             Replace code for non-CONST_INT constants with gcc_unreachable.
>             * config/m68k/m68k.md (cbranchdi): Don't generate individual
>             compare and test.
>             (CMPMODE): New mode_iterator.
>             (cbranchsi4, cbranchqi4, cbranchhi4): Replace expanders with
>             cbranch<mode>4.
>             (cstoresi4, cstoreqi4, cstorehi4): Replace expanders with
>             cstore<mode>4.
>             (cmp<mode>_68881): Remove 'F' constraint from first comparison
>             operand.
>             (bit test insns patterns): Use nonimmediate_operand, not
>             register_operand, for source operands that allow memory in
>             their constraints.
>             (divmodsi4, udivmodsi4, divmodhi4 and related unnamed patterns):
>             Use register_operand, not nonimmediate_operand, for the
>             destinations.
>             (DBCC): New mode_iterator.
>             (dbcc peepholes): Use it to reduce duplication.
>             (trap): Use const_true_rtx, not const1_rtx.
>             * config/m68k/predicates.md (m68k_comparison_operand): Renamed
>             from m68k_subword_comparison_operand and changed to handle
>             SImode.
OK.  I'd actually recommend this go ahead and get installed.  My tester
will bootstrap it overnight.

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/4] Preliminary m68k patches

Bernd Schmidt
On 11/13/19 9:03 PM, Jeff Law wrote:
> OK.  I'd actually recommend this go ahead and get installed.  My tester
> will bootstrap it overnight.

Alright, let me know how that turns out. What kind of machine do you
have for that?


Bernd
Reply | Threaded
Open this post in threaded view
|

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

Richard Henderson
In reply to this post by Jeff Law
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~
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
In reply to this post by Bernd Schmidt
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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
In reply to this post by Bernd Schmidt
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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

John Paul Adrian Glaubitz
In reply to this post by 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 - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Reply | Threaded
Open this post in threaded view
|

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

Bernd Schmidt
In reply to this post by Andreas Schwab-2
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
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schwab-2
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, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

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
12345