On Mon, Nov 25, 2019 at 03:44:44PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/25/19 3:40 PM, Segher Boessenkool wrote:
> > On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
> >> Thanks for the m68k work! Can you also update
> >> https://gcc.gnu.org/backends.html ?
> >
> >> PS:
On 11/28/19 8:53 PM, Gunther Nikl wrote:> Bernd Schmidt
:
>> On 11/23/19 9:53 PM, Bernd Schmidt wrote:
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's a movqi using move.w.
>
> Can this problem also happen on older
Bernd Schmidt :
> On 11/23/19 9:53 PM, Bernd Schmidt wrote:
> > I'll spend a few more days trying to see if I can do something
> > about the bootstrap failure Mikael saw (currently trying to do a
> > two-stage cross build rather than a really slow bootstrap).
>
> Whew, I think I have it. One
On Wed, Nov 27, 2019 at 12:18 AM Joseph Myers wrote:
>
> On Tue, 26 Nov 2019, Bernd Schmidt wrote:
>
> > On 11/26/19 3:21 AM, Joseph Myers wrote:
> > >
> > > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> > > --disable-multilib) successfully built libgcc and glibc, but ran into
On Tue, 26 Nov 2019, Bernd Schmidt wrote:
> On 11/26/19 3:21 AM, Joseph Myers wrote:
> >
> > The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> > --disable-multilib) successfully built libgcc and glibc, but ran into an
> > ICE building the glibc tests. Again, I've not bisected
Hi Bernd!
On 11/26/19 2:44 AM, Bernd Schmidt wrote:
> I overlooked a difference in the 68881 vs coldfire patterns when I
> combined them. They use different suffixes for register compares (I only
> spotted the different constraints).
>
> The following seems to fix the assembler failures. I
On 11/26/19 3:21 AM, Joseph Myers wrote:
>
> The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> --disable-multilib) successfully built libgcc and glibc, but ran into an
> ICE building the glibc tests. Again, I've not bisected but this commit
> seems likely to be responsible.
On Tue, 26 Nov 2019, Bernd Schmidt wrote:
> On 11/26/19 1:36 AM, Joseph Myers wrote:
> > I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> > bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> > building _mulsc3.o; I get assembler errors:
>
>
On 11/26/19 1:36 AM, Joseph Myers wrote:
> I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> building _mulsc3.o; I get assembler errors:
I overlooked a difference in the 68881 vs coldfire
On Mon, 25 Nov 2019, Bernd Schmidt wrote:
> On 11/23/19 6:36 PM, Jeff Law wrote:
>
> > Not really. I've already indicated to Bernd that he should go ahead and
> > commit the changes and we can iterate on any problems that arise.
>
> After the last fix, I did some more testing and since I feel
On 11/25/19 3:40 PM, Segher Boessenkool wrote:
> On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
>> Thanks for the m68k work! Can you also update
>> https://gcc.gnu.org/backends.html ?
>
>> PS: I wonder whether some other archs also should be updated on that web
>> page.
>
>
Hi!
On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
> PS: I wonder whether some other archs also should be updated on that web
> page.
Possibly. Probably?
But, do you have any particular
On Nov 25 2019, Bernd Schmidt wrote:
> On 11/25/19 12:26 PM, Andreas Schwab wrote:
>> On Nov 24 2019, Bernd Schmidt wrote:
>>
>>> Whew, I think I have it. One tst instruction eliminated when it
>>> shouldn't have been:
>>>
>>> move.w %a4,%d0
>>> - tst.b %d0
>>> - jeq .L352
On 11/25/19 1:38 PM, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
Committed as obvious.
Bernd
commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19
Author: Bernd Schmidt
Date: Mon Nov 25 13:48:08 2019 +0100
Change backends table
On 11/25/19 1:38 PM, Bernd Schmidt wrote:
> On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
>> Are all 4 + 2 patches in now? Thus, can we close the bug?
>
> We're missing one piece for better autoinc generation, but that's a
> small optimization issue. The cc0 conversion is complete.
On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
> Are all 4 + 2 patches in now? Thus, can we close the bug?
We're missing one piece for better autoinc generation, but that's a
small optimization issue. The cc0 conversion is complete.
Bernd
Hi Bernd,
Thanks for the m68k work! Can you also update
https://gcc.gnu.org/backends.html ?
(Webseite repo ist now in git, cf. https://gcc.gnu.org/about.html#git )
Cheers,
Tobias
PS: I wonder whether some other archs also should be updated on that web
page.
On 11/25/19 1:33 PM, Bernd
Hi Bernd!
On 11/25/19 1:33 PM, Bernd Schmidt wrote:
> On 11/23/19 6:36 PM, Jeff Law wrote:
>
>> Not really. I've already indicated to Bernd that he should go ahead and
>> commit the changes and we can iterate on any problems that arise.
>
> After the last fix, I did some more testing and since
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
After the last fix, I did some more testing and since I feel confident
that it really is in good shape now, I
On 11/25/19 12:26 PM, Andreas Schwab wrote:
> On Nov 24 2019, Bernd Schmidt wrote:
>
>> Whew, I think I have it. One tst instruction eliminated when it
>> shouldn't have been:
>>
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's
On Nov 24 2019, Bernd Schmidt wrote:
> Whew, I think I have it. One tst instruction eliminated when it
> shouldn't have been:
>
> move.w %a4,%d0
> - tst.b %d0
> - jeq .L352
> + jeq .L353
>
> And the reason - that's a movqi using move.w. The following should fix
> it.
On 11/23/19 12:54 PM, Oleg Endo wrote:
> On Sat, 2019-11-23 at 10:36 -0700, Jeff Law wrote:
>>
>>> Any news on this? I would be in favor of merging these patches as I
>>> have
>>> tested them successfully on Debian by building the gcc-snapshot
>>> package
>>> with the patches applied. I used all
On 11/23/19 9:53 PM, Bernd Schmidt wrote:
> I'll spend a few more days trying to see if I can do something about the
> bootstrap failure Mikael saw (currently trying to do a two-stage cross
> build rather than a really slow bootstrap).
Whew, I think I have it. One tst instruction eliminated when
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
In the meantime I've made an aranym setup in addition to the qemu setup
I had, and I've not been able to reproduce
On Sat, 2019-11-23 at 10:36 -0700, Jeff Law wrote:
>
> > Any news on this? I would be in favor of merging these patches as I
> > have
> > tested them successfully on Debian by building the gcc-snapshot
> > package
> > with the patches applied. I used all four patches plus the
> > additional one
>
On 11/23/19 10:14 AM, John Paul Adrian Glaubitz wrote:
> Hi Jeff!
>
>> On 11/13/19 6:23 AM, Bernd Schmidt wrote:
>>> Once more with patch.
>>>
>>>
>>> Bernd
>>>
>>>
>>> m68k-2.diff
>>>
>>> PR target/91851
>>> * config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
>>>
Hi Jeff!
> On 11/13/19 6:23 AM, Bernd Schmidt wrote:
>> Once more with patch.
>>
>>
>> Bernd
>>
>>
>> m68k-2.diff
>>
>> PR target/91851
>> * config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
>> declaration.
>> (m68k_init_cc): New
On 11/18/19 9:51 AM, Bernd Schmidt wrote:
> (Apologies to Jeff who's getting this twice because I didn't hit
> reply-all the first time.)
>
> On 11/17/19 6:56 PM, Jeff Law wrote:
>
>> While scanning this patch I did notice the introduction of
>> CC_STATUS_INIT in output_{and,ior,xor}si. You
(Apologies to Jeff who's getting this twice because I didn't hit
reply-all the first time.)
On 11/17/19 6:56 PM, Jeff Law wrote:
> While scanning this patch I did notice the introduction of
> CC_STATUS_INIT in output_{and,ior,xor}si. You might want to check that.
That is intentional.
On 11/13/19 6:23 AM, Bernd Schmidt wrote:
> Once more with patch.
>
>
> Bernd
>
>
> m68k-2.diff
>
> PR target/91851
> * config/m68k/m68k-protos.h (output-dbcc_and_branch): Adjust
> declaration.
> (m68k_init_cc): New declaration.
>
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,
31 matches
Mail list logo
