> It's a bit like writing a new backend, except you have all this existing
> code to worry about as well. Unless you start from scratch (which may
> not be such a bad idea: you get to modernise it all, and it isn't _really_
> from scratch, you can peek at the old code and copy stuff from it).
I
Hi!
On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
> On Fri, Jan 19 2018, Sandra Loosemore wrote:
> > On 01/19/2018 10:14 AM, Jeff Law wrote:
> >
> >> cc0 needs to die. That doesn't mean that any particular target needs to
> >> be dropped -- it just means that someone has to
> On Jan 22, 2018, at 5:17 AM, Trevor Saunders wrote:
>
> On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
>> Hi,
>>
>> On Fri, Jan 19 2018, Sandra Loosemore wrote:
>>> On 01/19/2018 10:14 AM, Jeff Law wrote:
>>>
cc0 needs to die. That doesn't mean
On Mon, Jan 22, 2018 at 10:57:35AM +0100, Martin Jambor wrote:
> Hi,
>
> On Fri, Jan 19 2018, Sandra Loosemore wrote:
> > On 01/19/2018 10:14 AM, Jeff Law wrote:
> >
> >> cc0 needs to die. That doesn't mean that any particular target needs to
> >> be dropped -- it just means that someone has to
Hi,
On Fri, Jan 19 2018, Sandra Loosemore wrote:
> On 01/19/2018 10:14 AM, Jeff Law wrote:
>
>> cc0 needs to die. That doesn't mean that any particular target needs to
>> be dropped -- it just means that someone has to step forward to do the
>> conversion.
>
> Unifying two parallel threads:
On 01/19/2018 10:14 AM, Jeff Law wrote:
cc0 needs to die. That doesn't mean that any particular target needs to
be dropped -- it just means that someone has to step forward to do the
conversion.
Unifying two parallel threads: might this be a good project for GSoC?
-Sandra
On Fri, Jan 19, 2018 at 07:58:02PM +0100, Eric Botcazou wrote:
> > - cc0 does a good job and did always a good job in the past. In the
> > years I contributed to avr, there hasn't been a single cc0 flaw (all the
> > few, minor cc0-related issues were avr BE issues).
cc0 does not do a good job at
> Yes, I know that CCmode can represent condition code. But just the fact
> that it can represent it doesn't make it superior or cc0 inferior or
> bad. Having different representations for the same thing has also its
> obvious upsides (think of different representations in maths or
> physics),
On 01/19/2018 06:33 AM, Georg-Johann Lay wrote:
> On 13.01.2018 00:07, Joseph Myers wrote:
>> On Fri, 12 Jan 2018, Jeff Law wrote:
>>
>>> I was going to suggest deprecation for gcc-8 given how badly it was
>>> broken in gcc-7 and the lack of maintenance on the target.
>>
>> While we're considering
On 13.01.2018 00:07, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7 and the lack of maintenance on the target.
While we're considering deprecations, what happened to the idea of setting
a timescale
Jeff Law writes:
> A change in reload back in 2016 (IIRC) has effectively made m32c
> unusable. The limits of the register file create horrible problems for
> reload.
>
> I was going to suggest deprecation for gcc-8 given how badly it was
> broken in gcc-7 and the lack of
On Mon, Jan 15, 2018 at 11:28:25AM -0700, Jeff Law wrote:
> > Is cc0 conversion enough to get m68k off the chopping block?
> I would think so for this round. I suspect there'd be another round in
> the future to convert to LRA, but I suspect that'd be *much* smaller.
Yeah. And converting to LRA
On 01/15/2018 11:11 AM, Joel Sherrill wrote:
>
>
> On 1/15/2018 11:31 AM, Segher Boessenkool wrote:
>> On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote:
>>> On 13/01/18 00:16, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Jeff Law
On 1/15/2018 11:31 AM, Segher Boessenkool wrote:
On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote:
On 13/01/18 00:16, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how
On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote:
> On 13/01/18 00:16, Jeff Law wrote:
> >On 01/12/2018 04:07 PM, Joseph Myers wrote:
> >>On Fri, 12 Jan 2018, Jeff Law wrote:
> >>
> >>>I was going to suggest deprecation for gcc-8 given how badly it was
> >>>broken in gcc-7 and the
On 01/15/2018 05:46 AM, Joseph Myers wrote:
On Mon, 15 Jan 2018, Sebastian Huber wrote:
On 13/01/18 00:16, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7
On Mon, 15 Jan 2018, Sebastian Huber wrote:
> On 13/01/18 00:16, Jeff Law wrote:
> > On 01/12/2018 04:07 PM, Joseph Myers wrote:
> > > On Fri, 12 Jan 2018, Jeff Law wrote:
> > >
> > > > I was going to suggest deprecation for gcc-8 given how badly it was
> > > > broken in gcc-7 and the lack of
On 13/01/18 00:16, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7 and the lack of maintenance on the target.
While we're considering deprecations, what
On 1/12/2018 5:40 PM, Segher Boessenkool wrote:
On Fri, Jan 12, 2018 at 05:29:29PM -0600, Joel Sherrill wrote:
What's the list of targets under consideration?
Anything that still uses cc0 when the cull is made.
Current targets using cc0 are:
h8300, v850, cris, pdp11, vax, cr16,
On Fri, Jan 12, 2018 at 05:29:29PM -0600, Joel Sherrill wrote:
> What's the list of targets under consideration?
Anything that still uses cc0 when the cull is made.
Current targets using cc0 are:
h8300, v850, cris, pdp11, vax, cr16, m68k, avr.
Segher
On 1/12/2018 5:16 PM, Jeff Law wrote:
On 01/12/2018 04:07 PM, Joseph Myers wrote:
On Fri, 12 Jan 2018, Jeff Law wrote:
I was going to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7 and the lack of maintenance on the target.
While we're considering deprecations, what
On 01/12/2018 04:07 PM, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Jeff Law wrote:
>
>> I was going to suggest deprecation for gcc-8 given how badly it was
>> broken in gcc-7 and the lack of maintenance on the target.
>
> While we're considering deprecations, what happened to the idea of setting
On Fri, 12 Jan 2018, Jeff Law wrote:
> I was going to suggest deprecation for gcc-8 given how badly it was
> broken in gcc-7 and the lack of maintenance on the target.
While we're considering deprecations, what happened to the idea of setting
a timescale by which cc0 targets need to be
Jeff Law writes:
> I was going to suggest deprecation for gcc-8 given how badly it was
> broken in gcc-7 and the lack of maintenance on the target.
As much as I use the m32c target, I have to agree. I've tried many
times to fix its reload problems to no avail, and just don't
On 01/12/2018 07:24 AM, Segher Boessenkool wrote:
> On Fri, Jan 12, 2018 at 08:02:40AM +0100, Sebastian Huber wrote:
>> what is the status of the m32c target? There are some open bugs that
>> prevent the C/C++ compiler build:
>>
>>
On Fri, Jan 12, 2018 at 08:02:40AM +0100, Sebastian Huber wrote:
> what is the status of the m32c target? There are some open bugs that
> prevent the C/C++ compiler build:
>
>
26 matches
Mail list logo