On Apr 23, 2005, at 7:40 PM, Hans-Peter Nilsson wrote:
On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote:
On Wed, 6 Apr 2005, Joseph S. Myers wrote:
(If test results for a port are so bad that
though sent to gcc-testresults they exceed the message size limit,
and
this remains the case for a prolonged
On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote:
> On Wed, 6 Apr 2005, Joseph S. Myers wrote:
> > (If test results for a port are so bad that
> > though sent to gcc-testresults they exceed the message size limit, and
> > this remains the case for a prolonged period such as ever since 4.0
> > branched
On Wed, 6 Apr 2005, Joseph S. Myers wrote:
> (If test results for a port are so bad that
> though sent to gcc-testresults they exceed the message size limit, and
> this remains the case for a prolonged period such as ever since 4.0
> branched, that also indicates lack of active maintenance.)
No, i
Am Freitag, 8. April 2005 01:06 schrieb Janis Johnson:
>
> I should have done that, I must have missed seeing your patch. I'll look
> for it now in the archives.
>
> Janis
I just had a look at the archives and found that the subject of the mail I
have been sending was not very clear either :-) (a
On Thu, Apr 07, 2005 at 11:20:46PM +0200, Björn Haase wrote:
>
> The reason why I have stopped posting the test results is that we are
> currently having 481 failures for the AVR target and the existing real bugs
> are completely hidden behind the huge number of failures due to issues like
> "t
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Joseph Myers wrote:
>One possible way of assessing activity would be to say that after 4.1
maintained CPU ports should have test results for mainline regularly
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at least if you start combining various options, and
including lan
Joseph S. Myers wrote:
One possible way of assessing activity would be to say that after 4.1
maintained CPU ports should have test results for mainline regularly sent
to gcc-testresults and monitored for regressions, though this rather
depends on the willingness of maintainers of embedded ports
Joel Sherrill <[EMAIL PROTECTED]> wrote:
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at least if you start co
Richard Earnshaw wrote:
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
Joe Buck wrote:
But if it won't even build, then users should be warned.
I suppose -- but we have relatively many configurations that probably
won't build, at least if you start combining various options, and
including lan
On Wed, 6 Apr 2005, Richard Earnshaw wrote:
> Maybe we need a third category - 'at risk'. Such a port will typically
> have no active maintainer, some likely serious bugs and might at some
> future date be obsoleted if no maintainer steps forward.
>
> We could put several ports into that categor
On Wed, 2005-04-06 at 00:30, Mark Mitchell wrote:
> Joe Buck wrote:
> >
> > But if it won't even build, then users should be warned.
>
> I suppose -- but we have relatively many configurations that probably
> won't build, at least if you start combining various options, and
> including langaug
Joe Buck wrote:
Kazu Hirata wrote:
I would like to propose that the c4x port be obsoleted for 4.0.
...
The primary reason is that the port doesn't build.
On Tue, Apr 05, 2005 at 02:44:38PM -0700, Mark Mitchell wrote:
I'm unpersuaded by the arguments later in the thread that we should keep
this po
Kazu Hirata wrote:
> >I would like to propose that the c4x port be obsoleted for 4.0.
> >...
> > The primary reason is that the port doesn't build.
On Tue, Apr 05, 2005 at 02:44:38PM -0700, Mark Mitchell wrote:
> I'm unpersuaded by the arguments later in the thread that we should keep
> this po
Kazu Hirata wrote:
Hi,
I would like to propose that the c4x port be obsoleted for 4.0.
c4x-*
tic4x-*
The primary reason is that the port doesn't build.
I'm unpersuaded by the arguments later in the thread that we should keep
this port for its pedagogical value as a BITS_PER_UNIT != 8 port. I
t
Kazu Hirata <[EMAIL PROTECTED]> writes:
> I would like to propose that the c4x port be obsoleted for 4.0.
>
> c4x-*
> tic4x-*
>
> The primary reason is that the port doesn't build.
>
> Richard Sandiford's recent patch allows us to go further during the
> build process, but the port still does
On Tue, Apr 05, 2005 at 02:30:47PM -0400, Paul Schlie wrote:
> > Kazu Hirata wrote:
> > I would like to propose that the c4x port be obsoleted for 4.0.
> >
> > c4x-*
> > tic4x-*
> >
> > The primary reason is that the port doesn't build.
> >
> > Richard Sandiford's recent patch allows us to go f
Original Message
>From: Paul Schlie
>Sent: 05 April 2005 19:31
> Although personally believe
Paul, the key in between the 'U' and the 'O' on your keyboard has been
broken for many months now!
cheers,
DaveK
--
Can't think of a witty .sigline today
> Kazu Hirata wrote:
> I would like to propose that the c4x port be obsoleted for 4.0.
>
> c4x-*
> tic4x-*
>
> The primary reason is that the port doesn't build.
>
> Richard Sandiford's recent patch allows us to go further during the
> build process, but the port still does not build.
Althoug
Hi,
I would like to propose that the c4x port be obsoleted for 4.0.
c4x-*
tic4x-*
The primary reason is that the port doesn't build.
Richard Sandiford's recent patch allows us to go further during the
build process, but the port still does not build.
http://gcc.gnu.org/ml/gcc-patches
20 matches
Mail list logo
