RE: Target deprecation list

RE: Target deprecation list

[Nitin Gupta]

Hi Joel,

> >         I just figured out sparclet-aout in your
deprecation
> >         list. I missed your first mail, probably
it bounced
> >         from my mail box.       I and "there are
1000 of us using this
> >         sparclet-aout port of GCC heavily all day
long and we were
> >         planning to upgrade to GCC 3.4" :)
> > 
> >         I'm currently upgrading it to GCC 3.2
which I'm almost through.
> >         I and our development team here have been
eagerly waiting for
> >         GCC 3.3 release, with which I'm planning
to do 
> regression testing,
> >         performance benchmarking of GCC for
various implementation of
> >         sparclet n/w processors after enabling
various new optimizations
> >         that come with GCC 3.3; DFA scheduler
contributed by 
> Vladimir being
> >         the first in pipeline.
> > 
> >         If required, I'm willing to volunteer to
maintain this
> >         port to keep it alive and evolve with
mighty GCC.
> 
> Is there any reason, you couldn't transition to the
sparc-elf target?
> Other than the obvious goal of eliminating targets
which don't have
> users, there is a simplification issue.  In this
case, sparc a.out
> systems are slowing disappearing and eventually gcc
may be able to
> remove all sparc/a.out support.   This also applies
to binutils 
> and gdb with respect to sparc/a.out.
> 
> ELF has been debug information and at this point in
time has a lot
> more activity.  You will have better support for C++
and other 
> languages on an ELF base target.

I'm looking forward to migrate to "sparclet-elf" and
willing to volunteer for the changes to be done.

However if the spaclet-aout is removed from the GCC 
3.3 release itself, the spaclet users would be 
deprived of the new optimizations that are planned 
for GCC 3.3. Please consider deprecating sparclet-aout
in 3.3 and removing in 3.4. By that time I may work on

and test "sparlet-elf" port.

> 
> If you have some download issue, you can always
configure the binutils
> to support conversion from ELF to a.out just to
create a download image.

Besides downloading, there are dependencies on aout 
stabs debug format in genereation of bin itself. So to

support ELF we need to make quite a lot of changes in 
our development framework too. I have just finished 
migrating our development environment from veteran 
egcs to GCC 3.2 and I had to make a few changes in our

framework due to the new stabs constructs being 
generated by GCC. To keep sync with lattest GCC 
releases we are willing to make further changes too, 
however it won't be feasible at such a short notice. 
If the community defers its plans  to 'remove' 
sparclet-aout till GCC 3.4 sparclet users
too would be able to keep pace with the GCC releases.

Thanks and Regards,
Nitin

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

Re: Target deprecation list

[Zack Weinberg]

Nitin Gupta <nitingccmail@yahoo.co.in> writes:

> framework due to the new stabs constructs being 
> generated by GCC. To keep sync with lattest GCC 
> releases we are willing to make further changes too, 
> however it won't be feasible at such a short notice. 
> If the community defers its plans  to 'remove' 
> sparclet-aout till GCC 3.4 sparclet users
> too would be able to keep pace with the GCC releases.

Just for the record, *all* the targets we are discussing removing
would be removed from GCC 3.4.  They would be present in GCC 3.3 but
would print a warning message when configured.

zw

Re: Target deprecation list

[Mark Mitchell]

> Assuming that patches to fix these issues were applied, what do I do
> beyond building the 3.2 branch periodically and letting the list know
> if something fails?

That's about it.  Maintainers are expected to deal with problems on
their platforms, and, ideally, answer questions as they arise.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Target deprecation list

[Jeff Epler]

[Jeff]
> > Is there any reasonable way to gage the amount of
> > time I'd need to devote, so that my proposal to my manager will be
> > reasonably accurate on that score?
> 
On Thu, Apr 17, 2003 at 04:20:52PM -0700, Mark Mitchell wrote:
> That's pretty hard to answer; it depends a lot on your experience, and
> on how many things don't quite work as expected on BSDI 2.1.

The list seems fairly small.

There are a pile of tests that fail because __attribute__((weak)) and
__attribute__((alias)) don't work.  I think that these just need to be made
expected errors.

Libiberty doesn't compile without a small tweak, because an included system
header requires another header to be included first. (this affects
binutils and gdb, too)

An additional fixinclude is needed to fix a bogus #define __attribute__ in
a header file (I sent a message about this to the list recently)

One libstdc++ file doesn't compile when -g is given.  I still don't
understand the reason for this, and have simply worked around it.

gdb compiles after i387.c (?) is added to a list of files to be linked in.

For all but the libstdc++ compilation problem, I can supply patches (though
if the libiberty problem is to be fixed by adding a #include, I suppose it
needs autoconfiscation I haven't done yet).  I'm not sure of the caues
of the libstdc++ issue, and I don't have the exact error at hand.


Assuming that patches to fix these issues were applied, what do I do
beyond building the 3.2 branch periodically and letting the list know
if something fails?

Jeff

Re: Target deprecation list

[Mark Mitchell]

> If I could offer my time, and the copyright assignment is not a problem,
> would it be accepted?  

I think so, but I don't speak for the SC.

> Is there any reasonable way to gage the amount of
> time I'd need to devote, so that my proposal to my manager will be
> reasonably accurate on that score?

That's pretty hard to answer; it depends a lot on your experience, and
on how many things don't quite work as expected on BSDI 2.1.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Target deprecation list

[Joel Sherrill]

Nitin Gupta wrote:
> 
> Hi Mark,
>         I just figured out sparclet-aout in your deprecation
>         list. I missed your first mail, probably it bounced
>         from my mail box.       I and "there are 1000 of us using this
>         sparclet-aout port of GCC heavily all day long and we were
>         planning to upgrade to GCC 3.4" :)
> 
>         I'm currently upgrading it to GCC 3.2 which I'm almost through.
>         I and our development team here have been eagerly waiting for
>         GCC 3.3 release, with which I'm planning to do regression testing,
>         performance benchmarking of GCC for various implementation of
>         sparclet n/w processors after enabling various new optimizations
>         that come with GCC 3.3; DFA scheduler contributed by Vladimir being
>         the first in pipeline.
> 
>         If required, I'm willing to volunteer to maintain this
>         port to keep it alive and evolve with mighty GCC.

Is there any reason, you couldn't transition to the sparc-elf target?
Other than the obvious goal of eliminating targets which don't have
users, there is a simplification issue.  In this case, sparc a.out
systems are slowing disappearing and eventually gcc may be able to
remove all sparc/a.out support.   This also applies to binutils 
and gdb with respect to sparc/a.out.

ELF has been debug information and at this point in time has a lot
more activity.  You will have better support for C++ and other 
languages on an ELF base target.

If you have some download issue, you can always configure the binutils
to support conversion from ELF to a.out just to create a download image.

> Thanks and Regards,
> Nitin
> 
> > -----Original Message-----
> > From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> > Mark Mitchell
> > Sent: Tuesday, April 15, 2003 12:53 PM
> > To: gcc@gcc.gnu.org
> > Subject: Target deprecation list
> >
> >
> >
> > A month ago, I posted a list of targets proposed for deprecation:
> >
> >   http://gcc.gnu.org/ml/gcc-announce/2003/msg00001.html
> >
> > I've received some replies from people who wanted to keep some of the
> > targets on that list.  I asked the folks that replied whether they
> > were using recent versions of GCC on their target; if they weren't, I
> > asked if they planned to do so.  (Some people just want to keep using
> > GCC 2.7.3, and they somehow thought we were going to take it away from
> > them.)
> >
> > Here are the ones we should keep, based on those discussions:
> >
> >   arc-*-*
> >
> >   hppa*-*-mpeix*
> >
> >   i?86-ncr-*
> >   i?86-sequent-*
> >   i?86-moss-*
> >   i?86-*-freebsd2*
> >   i?86-*-netbsd*aout*
> >   i?86-*-linux*aout*
> >   i?86-*-moss*
> >   i?86-*-sysv3*
> >   i?86-*-interix # not interix3
> >
> >   i960-*-*
> >
> >   m68000-hp-hpux*
> >   m68k-hp-hpux*
> >
> >   sparclite-*-coff*
> >
> >   vax-*-bsd*
> >   vax-*-netbsd*aout*
> >   vax-*-vms*
> >   vax-*-sysv*
> >
> > That means we can go ahead and lose both the m88k and ROMP targets
> > completely, even on the 3.3 branch, if someone is motivated to make
> > the changes.
> >
> > The other targets that were on the original list, but not on this
> > list, can go on the mainline -- but *not* on the 3.3 branch.
> >
> > Patches that do nothing but remove obsoleted targets are pre-approved,
> > starting in 48 hours so that in case other maintainers and/or the SC
> > can remove my pre-approval, if they feel it's inappropriate.
> >
> > --
> > Mark Mitchell
> > CodeSourcery, LLC
> > mark@codesourcery.com
> >
> >
> 
> ******************Legal Disclaimer**************************
> "This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email @globespanvirata.com, and delete the message. Thank you."
> ****************************************************************

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

RE: Target deprecation list

[Nitin Gupta]

Hi Mark,
	I just figured out sparclet-aout in your deprecation
	list. I missed your first mail, probably it bounced
	from my mail box.	I and "there are 1000 of us using this 
	sparclet-aout port of GCC heavily all day long and we were 
	planning to upgrade to GCC 3.4" :)

	I'm currently upgrading it to GCC 3.2 which I'm almost through. 
	I and our development team here have been eagerly waiting for 
	GCC 3.3 release, with which I'm planning to do regression testing, 
	performance benchmarking of GCC for various implementation of 
	sparclet n/w processors after enabling various new optimizations 
	that come with GCC 3.3; DFA scheduler contributed by Vladimir being 
	the first in pipeline.

	If required, I'm willing to volunteer to maintain this 
	port to keep it alive and evolve with mighty GCC.

Thanks and Regards,
Nitin


> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org]On Behalf Of
> Mark Mitchell
> Sent: Tuesday, April 15, 2003 12:53 PM
> To: gcc@gcc.gnu.org
> Subject: Target deprecation list
> 
> 
> 
> A month ago, I posted a list of targets proposed for deprecation:
> 
>   http://gcc.gnu.org/ml/gcc-announce/2003/msg00001.html
> 
> I've received some replies from people who wanted to keep some of the
> targets on that list.  I asked the folks that replied whether they
> were using recent versions of GCC on their target; if they weren't, I
> asked if they planned to do so.  (Some people just want to keep using
> GCC 2.7.3, and they somehow thought we were going to take it away from
> them.)
> 
> Here are the ones we should keep, based on those discussions:
> 
>   arc-*-*
> 
>   hppa*-*-mpeix*
> 
>   i?86-ncr-*
>   i?86-sequent-*
>   i?86-moss-*
>   i?86-*-freebsd2*
>   i?86-*-netbsd*aout*
>   i?86-*-linux*aout*
>   i?86-*-moss*
>   i?86-*-sysv3*
>   i?86-*-interix # not interix3
> 
>   i960-*-*
> 
>   m68000-hp-hpux*
>   m68k-hp-hpux*
> 
>   sparclite-*-coff*
> 
>   vax-*-bsd*        
>   vax-*-netbsd*aout*
>   vax-*-vms*
>   vax-*-sysv*
> 
> That means we can go ahead and lose both the m88k and ROMP targets
> completely, even on the 3.3 branch, if someone is motivated to make
> the changes.
> 
> The other targets that were on the original list, but not on this
> list, can go on the mainline -- but *not* on the 3.3 branch.
> 
> Patches that do nothing but remove obsoleted targets are pre-approved,
> starting in 48 hours so that in case other maintainers and/or the SC
> can remove my pre-approval, if they feel it's inappropriate.
> 
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> 
> 


******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient.  Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the message in error, please advise the sender by reply email @globespanvirata.com, and delete the message. Thank you."
****************************************************************

Re: Target deprecation list

[Eric Christopher]

> Perhaps so.  But getting rid of some stuff is certainly a good thing. 
> Once we've got the non-controversial bits removed, we can always come
> back and look at those architectures again.

This reminds me. binutils is removing mips-ecoff support so if it isn't
deprecated already it should be with 3.3 :)

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: Target deprecation list

[Jeff Epler]

My employer is still using i386-pc-bsdi2.1 (as a target).  I recently
managed to get 3.2.2 (languages c,c++) compiled in this configuration
with some difficulty.

I'd like to make the case to my managers that my time should be
allocated to be a gcc maintainer for this platform, which we will
continue to use and support for at least 18 months (but probably less
than 24).  If redhat moves to 3.3 or 3.4 within this timeframe, we might
follow suit, but otherwise we're likely to remain on the 3.2 branch.

If I could offer my time, and the copyright assignment is not a problem,
would it be accepted?  Is there any reasonable way to gage the amount of
time I'd need to devote, so that my proposal to my manager will be
reasonably accurate on that score?

What about binutils, gdb, libiberty(?) and other independantly maintained
projects that are all required to make gcc work and be useful?

Jeff Epler
jepler@unpythonic.net

Re: Target deprecation list

[Mark Mitchell]

On Tue, 2003-04-15 at 13:33, Richard Henderson wrote:
> On Tue, Apr 15, 2003 at 12:22:57AM -0700, Mark Mitchell wrote:
> > I asked the folks that replied whether they
> > were using recent versions of GCC on their target; if they weren't, I
> > asked if they planned to do so.
> 
> Even this is not enough.  Someone has to be willing to *maintain*
> this code.  Thus I think the requirements to keep 
> 
> >   arc-*-*
> >   i960-*-*
> 
> should be higher than for the others (which only keep os support
> for an otherwise maintained cpu).

Perhaps so.  But getting rid of some stuff is certainly a good thing. 
Once we've got the non-controversial bits removed, we can always come
back and look at those architectures again.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Target deprecation list

[Richard Henderson]

On Tue, Apr 15, 2003 at 12:22:57AM -0700, Mark Mitchell wrote:
> I asked the folks that replied whether they
> were using recent versions of GCC on their target; if they weren't, I
> asked if they planned to do so.

Even this is not enough.  Someone has to be willing to *maintain*
this code.  Thus I think the requirements to keep 

>   arc-*-*
>   i960-*-*

should be higher than for the others (which only keep os support
for an otherwise maintained cpu).



r~

Re: Target deprecation list

[Michael S. Zick]

On Tuesday 15 April 2003 02:22 am, Mark Mitchell wrote:
> A month ago, I posted a list of targets proposed for deprecation:
>
> (Some people just want to keep using
> GCC 2.7.3, and they somehow thought we were going to take it away from
> them.)
>
Isn't -
rpc(*.*:nuke(gcc-2.7.3))
part of the gcc libraries yet?

Mike

Target deprecation list

[Mark Mitchell]

A month ago, I posted a list of targets proposed for deprecation:

  http://gcc.gnu.org/ml/gcc-announce/2003/msg00001.html

I've received some replies from people who wanted to keep some of the
targets on that list.  I asked the folks that replied whether they
were using recent versions of GCC on their target; if they weren't, I
asked if they planned to do so.  (Some people just want to keep using
GCC 2.7.3, and they somehow thought we were going to take it away from
them.)

Here are the ones we should keep, based on those discussions:

  arc-*-*

  hppa*-*-mpeix*

  i?86-ncr-*
  i?86-sequent-*
  i?86-moss-*
  i?86-*-freebsd2*
  i?86-*-netbsd*aout*
  i?86-*-linux*aout*
  i?86-*-moss*
  i?86-*-sysv3*
  i?86-*-interix # not interix3

  i960-*-*

  m68000-hp-hpux*
  m68k-hp-hpux*

  sparclite-*-coff*

  vax-*-bsd*        
  vax-*-netbsd*aout*
  vax-*-vms*
  vax-*-sysv*

That means we can go ahead and lose both the m88k and ROMP targets
completely, even on the 3.3 branch, if someone is motivated to make
the changes.

The other targets that were on the original list, but not on this
list, can go on the mainline -- but *not* on the 3.3 branch.

Patches that do nothing but remove obsoleted targets are pre-approved,
starting in 48 hours so that in case other maintainers and/or the SC
can remove my pre-approval, if they feel it's inappropriate.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com