Re: patch/proposal: obsolete configurations in 3.1

Re: patch/proposal: obsolete configurations in 3.1

[Andi Kleen]

Zack Weinberg <zack@codesourcery.com> writes:
> 
> For GCC 3.1 I propose to mark the following configuration triples
> obsolete:
> 
> 	a29k-*-*

Hmm. I thought a29k was still used for some things, but it is EOLed.

> 	arm-*-riscix*
> 	c*-convex-*
> 	i[3456]86*-*-sunos*
> 	i[3456]86*-freebsd1.*
> 	i[3456]86*-freebsd2.[01]*
> 	m68[k0]*-altos-*
> 	m68[k0]*-isi-*
> 	m68[k0]*-sony-*
> 	ns32k-encore-bsd*
> 	ns32k-sequent-bsd*
> 	ns32k-tek6[12]00-bsd*
> 	ns32k-merlin-*
> 	ns32k-pc532-*

Here are some more proposals: 

pdp10-*
m68k-bull-sysv3
m68k-tektronix-bsd
pyramid-pyramid-svr4
m68010-convergent-sysv

-Andi

Re: patch/proposal: obsolete configurations in 3.1

[Kevin Handy]

Andi Kleen wrote:

>Zack Weinberg <zack@codesourcery.com> writes:
>
>>For GCC 3.1 I propose to mark the following configuration triples
>>obsolete:
>>
>>	a29k-*-*
>>
>
>Hmm. I thought a29k was still used for some things, but it is EOLed.
>
>>	arm-*-riscix*
>>	c*-convex-*
>>	i[3456]86*-*-sunos*
>>	i[3456]86*-freebsd1.*
>>	i[3456]86*-freebsd2.[01]*
>>	m68[k0]*-altos-*
>>	m68[k0]*-isi-*
>>	m68[k0]*-sony-*
>>	ns32k-encore-bsd*
>>	ns32k-sequent-bsd*
>>	ns32k-tek6[12]00-bsd*
>>	ns32k-merlin-*
>>	ns32k-pc532-*
>>
>
>Here are some more proposals: 
>
>pdp10-*
>
I wouldn't advise dropping the PDP10, since it is making a resurgance due
to the emulators that have become available. I believe this target is 
actually
fairly new.

>
>m68k-bull-sysv3
>m68k-tektronix-bsd
>pyramid-pyramid-svr4
>m68010-convergent-sysv
>
>

Re: patch/proposal: obsolete configurations in 3.1

[Zack Weinberg]

On Sun, Apr 14, 2002 at 04:18:45PM -0600, Kevin Handy wrote:
> Andi Kleen wrote:
> >
> >Here are some more proposals: 
> >
> >pdp10-*
> >
> I wouldn't advise dropping the PDP10, since it is making a
> resurgance due to the emulators that have become available. I
> believe this target is actually fairly new.

There isn't a PDP10 backend in the current official tree.  I know
people are working on one, though.  Andi, did you mean pdp11?

zw

Re: patch/proposal: obsolete configurations in 3.1

[Andi Kleen]

On Sun, Apr 14, 2002 at 11:23:13PM -0700, Zack Weinberg wrote:
> On Sun, Apr 14, 2002 at 04:18:45PM -0600, Kevin Handy wrote:
> > Andi Kleen wrote:
> > >
> > >Here are some more proposals: 
> > >
> > >pdp10-*
> > >
> > I wouldn't advise dropping the PDP10, since it is making a
> > resurgance due to the emulators that have become available. I
> > believe this target is actually fairly new.
> 
> There isn't a PDP10 backend in the current official tree.  I know
> people are working on one, though.  Andi, did you mean pdp11?

Yes, pdp11, sorry. But as it seems there are people using it still
it is probably better to keep it.

-Andi

Re: patch/proposal: obsolete configurations in 3.1

[Paul Koning]

Excerpt of message (sent 14 April 2002) by Zack Weinberg:
> On Sun, Apr 14, 2002 at 04:18:45PM -0600, Kevin Handy wrote:
> > Andi Kleen wrote:
> > >
> > >Here are some more proposals: 
> > >
> > >pdp10-*
> > >
> > I wouldn't advise dropping the PDP10, since it is making a
> > resurgance due to the emulators that have become available. I
> > believe this target is actually fairly new.
> 
> There isn't a PDP10 backend in the current official tree.  I know
> people are working on one, though.  Andi, did you mean pdp11?

I've been trying to make more progress on getting that one fixed...

     paul

Re: patch/proposal: obsolete configurations in 3.1

[Mark Mitchell]

>> pdp10-*
>>
> I wouldn't advise dropping the PDP10, since it is making a resurgance due
> to the emulators that have become available. I believe this target is
> actually fairly new.

I'm going to take a position here that I'll likely get flamed for, but
so be it.  The mere existence of hardware or an emulator for same does
not mean that GCC should support that target.  Neither does the existence
of a set of users for that target.  Instead, I believe that there should
be active development of new code for something approximating production
use by a relatively large number of people.  (People can always maintain
their own GCC port to any chip they like, but I don't think the FSF
should do so.)

Obviously, this is a grey area, but I can't imagine the PDP-10, even
in emulation, being used for new development.  (I do know that people
are running real applications on these emulators, but my understanding
was that many of these were old accounting applications for which the
source was no longer available.)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: patch/proposal: obsolete configurations in 3.1

[David S. Miller]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Mon, 15 Apr 2002 07:22:25 -0700

   Instead, I believe that there should
   be active development of new code for something approximating production
   use by a relatively large number of people.

I'll go out on a limb and say that there are probably more people
using the PDP10 stuff than MMIX. :-)

Re: patch/proposal: obsolete configurations in 3.1

[Mark Mitchell]

--On Monday, April 15, 2002 07:57:53 AM -0700 "David S. Miller" 
<davem@redhat.com> wrote:

>    From: Mark Mitchell <mark@codesourcery.com>
>    Date: Mon, 15 Apr 2002 07:22:25 -0700
>
>    Instead, I believe that there should
>    be active development of new code for something approximating
> production    use by a relatively large number of people.
>
> I'll go out on a limb and say that there are probably more people
> using the PDP10 stuff than MMIX. :-)

Indeed.

Had it been up to me, I would never have allowed the MMIX port to
be included in GCC.  I'm a huge fan of Knuth, but I'd much rather
we not be saddled with updating the MMIX port whenever we make a
change to GCC.

Oh, well....

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: patch/proposal: obsolete configurations in 3.1

[mike stump]

> Date: Mon, 15 Apr 2002 08:11:07 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> To: "David S. Miller" <davem@redhat.com>

> Had it been up to me, I would never have allowed the MMIX port to be
> included in GCC.  I'm a huge fan of Knuth, but I'd much rather we
> not be saddled with updating the MMIX port whenever we make a change
> to GCC.

You can make this happen.  Just fix and maintain the source code so
that these changes are not necessary.  [ ducking head ]

Re: patch/proposal: obsolete configurations in 3.1

[Mark Mitchell]

--On Monday, April 15, 2002 12:50:05 PM -0700 mike stump 
<mrs@windriver.com> wrote:

>> Date: Mon, 15 Apr 2002 08:11:07 -0700
>> From: Mark Mitchell <mark@codesourcery.com>
>> To: "David S. Miller" <davem@redhat.com>
>
>> Had it been up to me, I would never have allowed the MMIX port to be
>> included in GCC.  I'm a huge fan of Knuth, but I'd much rather we
>> not be saddled with updating the MMIX port whenever we make a change
>> to GCC.
>
> You can make this happen.  Just fix and maintain the source code so
> that these changes are not necessary.  [ ducking head ]

:-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: patch/proposal: obsolete configurations in 3.1

[Hans-Peter Nilsson]

On Mon, 15 Apr 2002, Mark Mitchell wrote:
> --On Monday, April 15, 2002 07:57:53 AM -0700 "David S. Miller"
> <davem@redhat.com> wrote:
>
> >    From: Mark Mitchell <mark@codesourcery.com>
> >    Date: Mon, 15 Apr 2002 07:22:25 -0700
> >
> >    Instead, I believe that there should
> >    be active development of new code for something approximating
> > production    use by a relatively large number of people.
> >
> > I'll go out on a limb and say that there are probably more people
> > using the PDP10 stuff than MMIX. :-)
>
> Indeed.
>
> Had it been up to me, I would never have allowed the MMIX port to
> be included in GCC.  I'm a huge fan of Knuth, but I'd much rather
> we not be saddled with updating the MMIX port whenever we make a
> change to GCC.
>
> Oh, well....

About that, let me just say I'm glad to see that others don't
share your view.

My 2 \"ore on the general subject of the number of ports being a
burden: I believe a general bug like in
<URL:http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00872.html>
would have remained much longer without the MMIX port, to be
seen for other targets only in large machine-generated codes.

To wit, more ports help fixing target-independent gcc bugs, if
nothing else than by exposing them.  The cost of keeping the
port up-to-date falls on the maintainer and should IMHO not be a
major subject when considering accepting a port in FSF sources.

Generic let's-change-some-target-macro-or-internal-interface
changes could supposedly be delegated to each port maintainer:
"Here's the patch that I committed for the main stuff and the
foobar port.  Gentlefolk, please tweak your ports accordingly."

brgds, H-P

Re: patch/proposal: obsolete configurations in 3.1

[David O'Brien]

On Tue, Apr 16, 2002 at 03:46:14AM -0400, Hans-Peter Nilsson wrote:
> Generic let's-change-some-target-macro-or-internal-interface
> changes could supposedly be delegated to each port maintainer:
> "Here's the patch that I committed for the main stuff and the
> foobar port.  Gentlefolk, please tweak your ports accordingly."

For that to work there would actually have to be active (and caring)
CPU maintainers.  I have repeatedly found them not to exist for all CPUs.
(some do have maintains that give TLC)

Re: patch/proposal: obsolete configurations in 3.1

[Daniel Egger]

Am Mon, 2002-04-15 um 16.57 schrieb David S. Miller:

> I'll go out on a limb and say that there are probably more people
> using the PDP10 stuff than MMIX. :-)

I doubt it. In faculties CS students will always have to learn different
types of assembly and in most cases x86 and growingly MMIX are the
languages of choice. Whether a compiler for such a theoretical machine
is really useful is a different matter though I can imagine that using
MMIX and the pipeline simulator might become a useful tool for gcc
performance testing.
 
-- 
Servus,
       Daniel

Re: patch/proposal: obsolete configurations in 3.1

[Hans-Peter Nilsson]

On 15 Apr 2002, Daniel Egger wrote:

> Am Mon, 2002-04-15 um 16.57 schrieb David S. Miller:
>
> > I'll go out on a limb and say that there are probably more people
> > using the PDP10 stuff than MMIX. :-)
>
> I doubt it. In faculties CS students will always have to learn different
> types of assembly and in most cases x86 and growingly MMIX are the
> languages of choice. Whether a compiler for such a theoretical machine
> is really useful is a different matter though I can imagine that using
> MMIX and the pipeline simulator might become a useful tool for gcc
> performance testing.

Patches for MMIX scheduling are welcome. ;-)

Exercise 1: Fix descriptions for Knuth's predefined plain and
deluxe *.mmconfig configurations.
Exercise 2: Script that at gcc build time reads a *.mmconfig and
 creates an included .md fragment, plus config machinery.
Exercise 3: Runtime configuration: mmix-gcc -mmconfig=something.mmconfig

(Every change supposedly backed up by performance figures.)

Something for projects/beginner.html perhaps.

brgds, H-P

Re: patch/proposal: obsolete configurations in 3.1

[Hans-Peter Nilsson]

On Mon, 15 Apr 2002, David S. Miller wrote:
> I'll go out on a limb and say that there are probably more people
> using the PDP10 stuff than MMIX. :-)

Definitely.  ... oh...

brgds, H-P

Re: patch/proposal: obsolete configurations in 3.1

[Richard Henderson]

On Mon, Apr 15, 2002 at 07:57:53AM -0700, David S. Miller wrote:
> I'll go out on a limb and say that there are probably more people
> using the PDP10 stuff than MMIX. :-)

True, but MMIX has an active maintainer, and that makes all the difference.

If H-P eventually gets tired of maintaining that port, and no one else
steps up, then MMIX will bit-rot and be removed.


r~

Re: patch/proposal: obsolete configurations in 3.1

[Lars Brinkhoff]

Mark Mitchell <mark@codesourcery.com> writes:
> > I wouldn't advise dropping the PDP10, since it is making a
> > resurgance due to the emulators that have become available. I
> > believe this target is actually fairly new.
> I'm going to take a position here that I'll likely get flamed for, but
> so be it.

No flames here.

> I can't imagine the PDP-10, even in emulation, being used for new
> development.

XKL, the company that pays for the port, certainly expects to be able
to use it for development of new code.  Of course, the number of
developers will be very small, less than a dozen.

(And anyway, the port in it's current form isn't fit for submission to
the FSF tree.)

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

Re: patch/proposal: obsolete configurations in 3.1

[Alan Lehotsky]

I'd like to take a middle position in this argument.

It seems to me that as long as a port has active maintainers that it 
is eminently reasonable to include it in the FSF GCC distribution. 
If it doesn't have a maintainer or an active community of users, then 
we should feel no compunction about dropping it from the distribution.

In the case of the PDP-10 port, there are some real benefits that 
will accrue from having GCC support.  The PDP-10 port will find (and 
hopefully fix) places where assumptions conserning

	- byte size (8 bits - DEC-10 supports bytes from 1..36 bits long!)
	- uniform pointers (DEC-10 has 3 different pointer formats)

It also gives us another example port to look at when trying to 
figure out how to accomplish things for a new port with some strange 
architectural features.

-- Al


At 7:22 AM -0700 4/15/02, Mark Mitchell wrote:
>>>pdp10-*
>>>
>>I wouldn't advise dropping the PDP10, since it is making a resurgance due
>>to the emulators that have become available. I believe this target is
>>actually fairly new.
>
>I'm going to take a position here that I'll likely get flamed for, but
>so be it.  The mere existence of hardware or an emulator for same does
>not mean that GCC should support that target.  Neither does the existence
>of a set of users for that target.  Instead, I believe that there should
>be active development of new code for something approximating production
>use by a relatively large number of people.  (People can always maintain
>their own GCC port to any chip they like, but I don't think the FSF
>should do so.)
>Obviously, this is a grey area, but I can't imagine the PDP-10, even
>in emulation, being used for new development.  (I do know that people
>are running real applications on these emulators, but my understanding
>was that many of these were old accounting applications for which the
>source was no longer available.)
>
>--
>Mark Mitchell                   mark@codesourcery.com
>CodeSourcery, LLC               http://www.codesourcery.com


-- 
		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
		          apl@alum.mit.edu
		          (978)287-0435 Voice
		          (978)808-6836 Cell

	Software Process Improvement / Management Consulting
	     Language Design / Compiler Implementation

Re: patch/proposal: obsolete configurations in 3.1

[Zack Weinberg]

I would like to avoid getting into a controversial policy debate two
weeks before 3.1 is released.  Therefore, I think that in 3.1 we
should deprecate only those targets that have no constituents at all.
For 3.2 we can talk about doing a broader sweep.

Here's my current proposed list:

	a29k-*-*
	arm-*-riscix*
	c*-convex-*
	elxsi-*-*
	i?86*-*-sunos*
	i?86*-*-freebsd1.*
	i?86*-*-linux*oldld*
	m68[k0]*-altos-*
	m68[k0]*-bull-*
	m68[k0]*-convergent-*
	m68[k0]*-isi-*
	m68[k0]*-sony-*
	m68[k0]*-tektronix-*
	ns32k-encore-bsd*
	ns32k-sequent-bsd*
	ns32k-tek6[12]00-bsd*
	ns32k-merlin-*
	ns32k-pc532-*

There are a LOT of weird proprietary-Unix m68k and i386 ports.  Would
someone more familiar with the history care to look through this list
and suggest more culls?

	m68000-att-sysv*
	m68000-hp-bsd*
	m68000-hp-hpux*
	m68000-sun-sunos3*
	m68000-sun-sunos4*
	m68k-*-lynxos*
	m68k-*-psos*
	m68k-*-sysv3*
	m68k-*-sysv4*
	m68k-apollo-*
	m68k-apple-aux*
	m68k-atari-sysv4*
	m68k-cbm-sysv4*
	m68k-ccur-rtu
	m68k-crds-unos*
	m68k-hp-bsd*
	m68k-hp-bsd4.4*
	m68k-hp-hpux*
	m68k-hp-hpux7*
	m68k-motorola-sysv*
	m68k-ncr-sysv*
	m68k-next-nextstep2*
	m68k-next-nextstep[34]*
	m68k-plexus-sysv*
	m68k-sun-mach*
	m68k-sun-sunos*
	m68k-sun-sunos3*
	m68k-tti-*
	i?86-*-bsd386*
	i?86-*-moss*
	i?86-sequent-sysv3*
	i?86-sequent-sysv4*
        i386-sun-sunos*
        i?86-*-bsd*
        i?86-*-bsdi*
        i?86-*-chorusos*
        i?86-*-isc*
        i?86-*-lynxos*
        i?86-*-mach*
        i?86-*-netware
        i?86-*-osf1*
        i?86-*-osfrose*
        i?86-*-sco3.2v5*
        i?86-*-sysv*
        i?86-*-sysv4*
        i?86-*-sysv5*
        i?86-*-udk*
        i?86-*-vsta
        i?86-dg-dgux*
        i?86-ibm-aix*
        i?86-moss-msdos*
        i?86-ncr-sysv4*
        i?86-next-*
        i?86-sequent-bsd*
        i?86-sequent-ptx1*
        i?86-sequent-ptx2*
        i?86-sequent-ptx4*

zw

Re: patch/proposal: obsolete configurations in 3.1

[Mark Mitchell]

--On Monday, April 15, 2002 10:05:42 AM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> I would like to avoid getting into a controversial policy debate two
> weeks before 3.1 is released.  Therefore, I think that in 3.1 we
> should deprecate only those targets that have no constituents at all.

That's very statesmanlike.  I agree.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: patch/proposal: obsolete configurations in 3.1

[Janis Johnson]

On Mon, Apr 15, 2002 at 10:05:42AM -0700, Zack Weinberg wrote:
> 
> There are a LOT of weird proprietary-Unix m68k and i386 ports.  Would
> someone more familiar with the history care to look through this list
> and suggest more culls?
> 
> 	i?86-sequent-sysv3*
> 	i?86-sequent-sysv4*
>         i?86-sequent-bsd*
>         i?86-sequent-ptx1*
>         i?86-sequent-ptx2*

These can probably all be dropped.  Most of them are for operating
systems that Sequent stopped supporting many years ago.  The most
recent, ptx2, wasn't upgraded for Y2K changes and hasn't been
supported since.

>         i?86-sequent-ptx4*

This is still in use.

Janis
(formerly of the Sequent compiler group)

Re: patch/proposal: obsolete configurations in 3.1

[Jason Merrill]

>>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:

>> i?86-sequent-sysv3*
>> i?86-sequent-sysv4*
>> i?86-sequent-bsd*
>> i?86-sequent-ptx1*
>> i?86-sequent-ptx2*

> These can probably all be dropped.  Most of them are for operating
> systems that Sequent stopped supporting many years ago.

Ah, Dynix; my first work on the GNU tools was porting various bits to
i386-sequent-bsd for the CS Dept's 4-way Symmetry.  But that was a long
time ago...

Jason

Re: patch/proposal: obsolete configurations in 3.1

[Stan Shebs]

Zack Weinberg wrote:
> 
>         m68k-*-lynxos*

This one was pretty shaky when it was alive, and it looks like
Lynx^H^H^H^HLynuxworks is only doing PPC, x86, and Mips nowadays.

>         m68k-*-sysv3*

Strictly nostalgia.

>         m68k-apollo-*

More nostalgia.

>         m68k-apple-aux*

Dead for many years.

>         m68k-next-nextstep2*
>         m68k-next-nextstep[34]*

Somebody was trying to revive this a year or two ago I think.
Another nostalgia thing though, we can dump a lot of code if
we suppress the feelings for bygone days and get rid of the
support for original NeXT cubes.

>         i?86-next-*

Likewise.

Stan

Re: patch/proposal: obsolete configurations in 3.1

[Zack Weinberg]

On Mon, Apr 15, 2002 at 05:59:50PM -0700, Stan Shebs wrote:
> Zack Weinberg wrote:
> >         m68k-next-nextstep2*
> >         m68k-next-nextstep[34]*
> 
> Somebody was trying to revive this a year or two ago I think.
> Another nostalgia thing though, we can dump a lot of code if
> we suppress the feelings for bygone days and get rid of the
> support for original NeXT cubes.

Looking through the mailing list archives, I see a patch from Kaveh
Ghazi last November, and then nothing since 1998.  Kaveh, do you still
have an active interest in this target?

zw

Re: patch/proposal: obsolete configurations in 3.1

[Kaveh R. Ghazi]

 > From: Zack Weinberg <zack@codesourcery.com>
 > 
 > On Mon, Apr 15, 2002 at 05:59:50PM -0700, Stan Shebs wrote:
 > > Zack Weinberg wrote:
 > > >         m68k-next-nextstep2*
 > > >         m68k-next-nextstep[34]*
 > > 
 > > Somebody was trying to revive this a year or two ago I think.
 > > Another nostalgia thing though, we can dump a lot of code if
 > > we suppress the feelings for bygone days and get rid of the
 > > support for original NeXT cubes.
 > 
 > Looking through the mailing list archives, I see a patch from Kaveh
 > Ghazi last November, and then nothing since 1998.  Kaveh, do you still
 > have an active interest in this target?
 > zw

Nope.

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Re: patch/proposal: obsolete configurations in 3.1

[Kai Henningsen]

On 15 Apr 2002 at 10:05, Zack Weinberg wrote:

> I would like to avoid getting into a controversial policy debate two
> weeks before 3.1 is released.  Therefore, I think that in 3.1 we
> should deprecate only those targets that have no constituents at all.
> For 3.2 we can talk about doing a broader sweep.

For 3.2, how about a (published enough in advance, of course) policy 
that everything goes for which there isn't either a "successful 
built" report or submitted testresults for the last N releases (or 
possibly N months)?

I'm assuming this would also catch anything actively supported, 
because submitting testresults wouldn't be a significant burden on 
whoever does that support.

For a later version, that could then be strengthened to at least a 
successful bootstrap.

I'm assuming here that as long as a configuration does successfully 
bootstrap, keeping it around cannot be that big a burden - sort of 
proof by success.

To make that work, the list of "verified" configurations, with last-
verified-at version or date (whatever the actual criterion is), could 
be listed on a web page, so users can easily find out if submitting 
either report would be a bright idea to keep one's port active.

Something along these lines would, it seems to me, make unnecessary 
these long threads building lists of configurations that can removed 
this time.

"No, I still have one customer for this port!" - "Ok, where's your 
build report and/or testresults? You're still using 2.8? Then why 
should we care if 3.5 supports that config? Next!"

Regards - Kai Henningsen

-- 
http://www.cats.ms
Spuentrup CTI       Fon: +49 700 CALL CATS (=22 55 22 87)
Windbreede 12       Fax: +49 251 322312 99
D-48157 Muenster    Mob: +49 161 322312 1
Germany             GSM: +49 171 7755060

Re: patch/proposal: obsolete configurations in 3.1

[Paul Koning]

Excerpt of message (sent 18 April 2002) by Kai Henningsen:
> On 15 Apr 2002 at 10:05, Zack Weinberg wrote:
> 
> > I would like to avoid getting into a controversial policy debate two
> > weeks before 3.1 is released.  Therefore, I think that in 3.1 we
> > should deprecate only those targets that have no constituents at all.
> > For 3.2 we can talk about doing a broader sweep.
> 
> For 3.2, how about a (published enough in advance, of course) policy 
> that everything goes for which there isn't either a "successful 
> built" report or submitted testresults for the last N releases (or 
> possibly N months)?

Interesting notion.  Does that depend on the existence of a simulator
for the target?  (is there an MMIX simulator??)

> For a later version, that could then be strengthened to at least a 
> successful bootstrap.

That doesn't work for embedded targets, which can't be bootstrapped,
they can only be crosscompilers.
 
	paul

Re: patch/proposal: obsolete configurations in 3.1

[Hans-Peter Nilsson]

On Thu, 18 Apr 2002, Paul Koning wrote:
> Excerpt of message (sent 18 April 2002) by Kai Henningsen:
> > For 3.2, how about a (published enough in advance, of course) policy
> > that everything goes for which there isn't either a "successful
> > built" report or submitted testresults for the last N releases (or
> > possibly N months)?
>
> Interesting notion.  Does that depend on the existence of a simulator
> for the target?

That or availability of a test-board or other similar cross-test
environment for non-self-hosted targets.

>  (is there an MMIX simulator??)

Please see the MMIX entry on <URL:http://gcc.gnu.org/readings.html>.
(Two clicks away.)

brgds, H-P

Re: patch/proposal: obsolete configurations in 3.1

[mike stump]

> Date: Mon, 15 Apr 2002 07:22:25 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> To: Kevin Handy <kth@srv.net>, Andi Kleen <ak@suse.de>
> cc: Zack Weinberg <zack@codesourcery.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> I'm going to take a position here that I'll likely get flamed for,
> but so be it.  The mere existence of hardware or an emulator for
> same does not mean that GCC should support that target.  Neither
> does the existence of a set of users for that target.  Instead, I
> believe that there should be active development of new code for
> something approximating production use by a relatively large number
> of people.  (People can always maintain their own GCC port to any
> chip they like, but I don't think the FSF should do so.)

Can i be the first?

I don't think this is the right approach.  I think the right approach
is to encourage any and all ports, for any and all reasons that people
might have to do a port.  I think it is not our job to artificially
limit or restrict it in general.

Now, what are the limits...  Well, if someone wanted to come along for
little good reason and upturn the entire source base just to support a
new weird whizzbang port, we should carefully consider if that would
be good or bad, and rule on a case-by-case basis.

Now, should we hold up a release for work X (relating to a weird
port), generally not.  Should we actively seek and recruit people to
work on a weird port, no, generally speaking, that isn't our job.
Should we worry and expend great energy about such a port, ah, maybe
not.

Re: patch/proposal: obsolete configurations in 3.1

[Phil Edwards]

On Mon, Apr 15, 2002 at 07:22:25AM -0700, Mark Mitchell wrote:
> 
> I'm going to take a position here that I'll likely get flamed for, but
> so be it.  The mere existence of hardware or an emulator for same does
> not mean that GCC should support that target.  Neither does the existence
> of a set of users for that target.

A related observation:

We've had one or two complaints about the large size of the source
tree downloads; the bulk was not in the multiple front-ends or runtime
libraries, but the size of config/* for all the back-ends.  We've made
available different tarballs for different language combinations, but Ye
Olde x86/Linuxe Usere must still download configury for all the platforms
we might possibly support.

The cleanup of config/* seems to be proceeding well.  If the bits become
unentangled enough, it would be nice to consider separating tarballs along
platform lines instead of / in addition to language lines.

Maybe have something like "if you're just going to be building a native
compiler for our 3 most popular platforms, grab these tiny tarballs,
else grab the whole thing."


The cleaner config/* might allow users interested in oddball platforms
to more easily distribute support for those cases:  "Go get GCC,
then download this tarball, which unpacks a new config directory in
gcc/config/stone-knives-and-bearskins."

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: patch/proposal: obsolete configurations in 3.1

[DJ Delorie]

> Maybe have something like "if you're just going to be building a native
> compiler for our 3 most popular platforms, grab these tiny tarballs,
> else grab the whole thing."

Old news for DJGPP.  Our source distributions are stripped of most of
the files that aren't used for a DJGPP native build.  The files are
about 60% of their original size that way.

Re: patch/proposal: obsolete configurations in 3.1

[Phil Edwards]

On Mon, Apr 15, 2002 at 10:42:59PM -0400, DJ Delorie wrote:
> 
> > Maybe have something like "if you're just going to be building a native
> > compiler for our 3 most popular platforms, grab these tiny tarballs,
> > else grab the whole thing."
> 
> Old news for DJGPP.  Our source distributions are stripped of most of
> the files that aren't used for a DJGPP native build.  The files are
> about 60% of their original size that way.

I thought about this some more while in the shower.  Maybe downloading a
release should involve:

1.  "Download this tar.bz2 file.  It is the core C compiler and middle-end
pieces, with no other language support, and no back-end support."

2.  "Optionally, download these tarballs to support additional languages,
such as C++, FORTRAN, Java, treelang, and Brainfunct."

3.  "Download the config-*.tar.bz2 file(s) for the platform(s) you wish
to support.  At least one platform backend file must be downloaded."

    "If this becomes confusing, download classic.tar.bz2 (50 MB), which is
the traditional supports-everything tarball."



Phil
yes i still occasionally play with a brainfunct frontend for gcc

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: patch/proposal: obsolete configurations in 3.1

[DJ Delorie]

You could only get away with that if you had a web form where the user
checked off everything they wanted, and it produced a list of files to
download.  We do this for DJGPP because the list of files and
installation instructions depend on each other and the variant of
dos/windows/whatever you're installing on.

You could split out the backends if configure were smart enough to
realize that a configuration is supported but missing.  You don't want
a random error here.

Re: patch/proposal: obsolete configurations in 3.1

[Paul Koning]

Excerpt of message (sent 15 April 2002) by Phil Edwards:
> On Mon, Apr 15, 2002 at 10:42:59PM -0400, DJ Delorie wrote:
> > 
> > > Maybe have something like "if you're just going to be building a native
> > > compiler for our 3 most popular platforms, grab these tiny tarballs,
> > > else grab the whole thing."
> > 
> > Old news for DJGPP.  Our source distributions are stripped of most of
> > the files that aren't used for a DJGPP native build.  The files are
> > about 60% of their original size that way.
> 
> I thought about this some more while in the shower.  Maybe downloading a
> release should involve:
> 
> 1.  "Download this tar.bz2 file.  It is the core C compiler and middle-end
> pieces, with no other language support, and no back-end support."
> 
> 2.  "Optionally, download these tarballs to support additional languages,
> such as C++, FORTRAN, Java, treelang, and Brainfunct."
> 
> 3.  "Download the config-*.tar.bz2 file(s) for the platform(s) you wish
> to support.  At least one platform backend file must be downloaded."

I'm not convinced the config/* subtree is big enough to make that much
extra complexity worth dealing with.

If you really want to have a "trimmed config" tarball, I'd suggest
splitting it just two ways: the "most popular targets" (which are in
the core C tarball) and the "all targets" supplemental tarball.

Then all that's left is to live through the debate about what's "most
popular". :-)

	  paul

Re: patch/proposal: obsolete configurations in 3.1

[Neil Booth]

Phil Edwards wrote:-

> The cleanup of config/* seems to be proceeding well.

Wow, you're optimistic!  Not to denegrate the hard work many have done
there, but I see so much work to do in config/* and isolating target
dependence within GCC's internals that it scares me.

Neil.

Re: patch/proposal: obsolete configurations in 3.1

[Phil Edwards]

On Tue, Apr 16, 2002 at 06:39:49AM +0100, Neil Booth wrote:
> Phil Edwards wrote:-
> 
> > The cleanup of config/* seems to be proceeding well.
> 
> Wow, you're optimistic!

I only said "proceeding," not "nearing completion."  :-)

If we move from 8 percent done to 9 percent done in a reasonable amount
of time, that's proceeding well -- but doesn't change the fact that we're
only 9 percent done.


> Not to denegrate the hard work many have done
> there, but I see so much work to do in config/* and isolating target
> dependence within GCC's internals that it scares me.

Yeah... this is one of the projects that I'd love to see done but am not
capable of doing.  It would seem that a specs overhaul/replacement would
also help in this area.  (Heck, is there a facet of GCC that /wouldn't/
be improved by replacing or at least reworking specs?)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: patch/proposal: obsolete configurations in 3.1

[Zack Weinberg]

On Mon, Apr 15, 2002 at 10:10:07PM -0400, Phil Edwards wrote:
> 
> The cleanup of config/* seems to be proceeding well.  If the bits become
> unentangled enough, it would be nice to consider separating tarballs along
> platform lines instead of / in addition to language lines.

To facilitate this we would need to fracture config.gcc into many
pieces, one per config subdirectory.  There is no technical difficulty
with doing that - we'd just replace the big case statement with

for arch in $srcdir/config/*/*.cf
do
	. $arch
	if [ x"$something_or_other" != x ]; then
		break
	fi
done

It's not clear what $something_or_other would be.  We might have to
get rid of the default stuff.

Thoughts?

zw

Re: patch/proposal: obsolete configurations in 3.1

[DJ Delorie]

> Thoughts?

It would be better to leave config.gcc monolithic.  If it selects a
file that doesn't exist, we can tell the user that they need to
install the configuration for that host/target.  With your idea,
there's no difference between "forgot to install" and "unsupported".

Besides, the split-up is only for distribution and installation.
Developers will still see the whole CVS tree anyway.

Re: patch/proposal: obsolete configurations in 3.1

[Phil Edwards]

On Wed, Apr 17, 2002 at 09:35:28PM -0400, DJ Delorie wrote:
> 
> > Thoughts?
> 
> It would be better to leave config.gcc monolithic.  If it selects a
> file that doesn't exist, we can tell the user that they need to
> install the configuration for that host/target.  With your idea,
> there's no difference between "forgot to install" and "unsupported".

Very true.

> Besides, the split-up is only for distribution and installation.
> Developers will still see the whole CVS tree anyway.

Also true.  I can't think of a way right now to make this split harmless.
Quite possibly not worth it.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: patch/proposal: obsolete configurations in 3.1

[Hans-Peter Nilsson]

On Wed, 17 Apr 2002, Zack Weinberg wrote:
> On Mon, Apr 15, 2002 at 10:10:07PM -0400, Phil Edwards wrote:
> >
> > The cleanup of config/* seems to be proceeding well.  If the bits become
> > unentangled enough, it would be nice to consider separating tarballs along
> > platform lines instead of / in addition to language lines.
>
> To facilitate this we would need to fracture config.gcc into many
> pieces, one per config subdirectory.  There is no technical difficulty
> with doing that - we'd just replace the big case statement with
>
> for arch in $srcdir/config/*/*.cf
> do
> 	. $arch
> 	if [ x"$something_or_other" != x ]; then
> 		break
> 	fi
> done

IIRC you recently moved a lot of stuff from config/* with one
positive aspect that there are fewer target snippets lying
rotting in a corner.  This sounds like you're proposing to move
stuff back.  Not good.

brgds, H-P

Re: patch/proposal: obsolete configurations in 3.1

[Zack Weinberg]

On Sun, Apr 14, 2002 at 07:34:45PM +0200, Andi Kleen wrote:
> Zack Weinberg <zack@codesourcery.com> writes:
> > For GCC 3.1 I propose to mark the following configuration triples
> > obsolete:
> > 
> > 	a29k-*-*
> 
> Hmm. I thought a29k was still used for some things, but it is EOLed.

Just going by what GDB's done.  If it is still in use, no doubt we'll
hear about it.

> pyramid-pyramid-svr4

No such animal, at least in the official tree.

zw

Re: patch/proposal: obsolete configurations in 3.1

[Stan Shebs]

Zack Weinberg wrote:
> 
> On Sun, Apr 14, 2002 at 07:34:45PM +0200, Andi Kleen wrote:
> > Zack Weinberg <zack@codesourcery.com> writes:
> > > For GCC 3.1 I propose to mark the following configuration triples
> > > obsolete:
> > >
> > >     a29k-*-*
> >
> > Hmm. I thought a29k was still used for some things, but it is EOLed.
> 
> Just going by what GDB's done.  If it is still in use, no doubt we'll
> hear about it.

I was a little surprised when Andrew proposed it, but if you poke
around the Web, you'll see that AMD now disavows that it ever
existed :-), and all of the remaining a29k refs are within GNU
sources themselves.  Not much point in supporting an embedded
architecture that's no longer being manufactured, thus not being
used in any new designs with code to be compiled.

> > pyramid-pyramid-svr4
> 
> No such animal, at least in the official tree.

I think the GCC support disappeared long before the GDB support,
possibly in the 1->2 transition.

Stan

Re: patch/proposal: obsolete configurations in 3.1

[David O'Brien]

On Sun, Apr 14, 2002 at 07:34:45PM +0200, Andi Kleen wrote:
> Here are some more proposals: 
> 
> pdp10-*
> m68k-bull-sysv3
> m68k-tektronix-bsd
> pyramid-pyramid-svr4
> m68010-convergent-sysv

After my last configurary header cleanup in config/i386, I really have to
wonder if any of these can go.  (I believe I did see some interix
activity this month, though)

    i386-sun-sunos*)		# Sun i386 roadrunner
    i[34567]86-*-aout*)
    i[34567]86-*-bsd*)
    i[34567]86-*-coff*)
    i[34567]86-*-isc*)		# 80386 running ISC system
    i[34567]86-*-linux*oldld*)	# Intel 80386's running GNU/Linux
    i[34567]86-*-linux*aout*)	# Intel 80386's running GNU/Linux
    i[34567]86-*-linux*libc1)	# Intel 80386's running GNU/Linux
    i[34567]86-*-mach*)
    i[34567]86-*-osfrose*)		# 386 using OSF/rose
    i[34567]86-*-sco3.2v5*)	# 80386 running SCO Open Server 5
    i[34567]86-*-udk*)      # Intel x86 on SCO UW/OSR5 Dev Kit
    i[34567]86-*-osf1*)		# Intel 80386's running OSF/1 1.3+
    i386-*-vsta)			# Intel 80386's running VSTa kernel
    i[34567]86-*-interix3*)
    i[34567]86-*-interix*)

Re: patch/proposal: obsolete configurations in 3.1

[Douglas B. Rupp]

Not obsolete! 

>   i[34567]86-*-interix3*)
>   i[34567]86-*-interix*)

Re: patch/proposal: obsolete configurations in 3.1

[Joel Sherrill]

David O'Brien wrote:
> 
>
>     i[34567]86-*-aout*)
>     i[34567]86-*-coff*)

In general, any target of the form CPU-*-OBJECT_FORMAT* should be
left in since it is a very basic target to use as a baseline for
a port and they are commonly used in the embedded world.

-- 
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: patch/proposal: obsolete configurations in 3.1

[Paul Koning]

Excerpt of message (sent 16 April 2002) by Joel Sherrill:
> 
> 
> David O'Brien wrote:
> > 
> >
> >     i[34567]86-*-aout*)
> >     i[34567]86-*-coff*)
> 
> In general, any target of the form CPU-*-OBJECT_FORMAT* should be
> left in since it is a very basic target to use as a baseline for
> a port and they are commonly used in the embedded world.

I'll second that.  If I need GCC for some RTOS, the first step is to
start with a "generic" target like that.  Quite often, that's all
that's needed.

       paul

Re: patch/proposal: obsolete configurations in 3.1

[Joel Sherrill]

Paul Koning wrote:
> 
> Excerpt of message (sent 16 April 2002) by Joel Sherrill:
> >
> >
> > David O'Brien wrote:
> > >
> > >
> > >     i[34567]86-*-aout*)
> > >     i[34567]86-*-coff*)
> >
> > In general, any target of the form CPU-*-OBJECT_FORMAT* should be
> > left in since it is a very basic target to use as a baseline for
> > a port and they are commonly used in the embedded world.
> 
> I'll second that.  If I need GCC for some RTOS, the first step is to
> start with a "generic" target like that.  Quite often, that's all
> that's needed.

I should have also added that many of them correspond to simulator
targets in gdb and are used for generic cross testing of the 
code generation.  Many bugs tend to be CPU not OS specific so
this is very useful.  Consequently, I try to duplicate bugs
found in rtems targets in generic object format targets to
indicate they are applicable across all targets in the CPU
family.

>        paul

-- 
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: patch/proposal: obsolete configurations in 3.1

[Richard Earnshaw]

Zack Weinberg <zack@codesourcery.com> writes:
> 
> For GCC 3.1 I propose to mark the following configuration triples
> obsolete:
> 
> 	a29k-*-*
> 	arm-*-riscix*

I think this is pretty much dead now.  I still have one, but I haven't 
switched it on in a couple of years.  I certainly wouldn't dream of trying 
to bootstrap gcc on it any more (it only has 8M of RAM).

> 	c*-convex-*
> 	i[3456]86*-*-sunos*
> 	i[3456]86*-freebsd1.*
> 	i[3456]86*-freebsd2.[01]*
> 	m68[k0]*-altos-*
> 	m68[k0]*-isi-*
> 	m68[k0]*-sony-*
> 	ns32k-encore-bsd*
> 	ns32k-sequent-bsd*
> 	ns32k-tek6[12]00-bsd*
> 	ns32k-merlin-*
> 	ns32k-pc532-*


I'd be inclined to add arm*-*-aof*.  That assembler syntax was never 
really supported.

R.

Re: patch/proposal: obsolete configurations in 3.1

[Nick Burrett]

Richard Earnshaw <rearnsha@arm.com> writes:

> Zack Weinberg <zack@codesourcery.com> writes:
> > 
> > For GCC 3.1 I propose to mark the following configuration triples
> > obsolete:
> > 
> 
> I'd be inclined to add arm*-*-aof*.  That assembler syntax was never 
> really supported.

The arm-*-aof stuff is still used, albeit in a slightly modified form,
in a version of GCC for RISC OS which I occasionally maintain.

Nick. 

RE: patch/proposal: obsolete configurations in 3.1

[Dana, Eric]

Jason,

   Please do not remove i?86-sequent-sysv4*. We are currently using it
   at my company. Also, I maintain the compiler for my company and will
   sending a patch for 3.1.1 support (rather trivial).

   FYI: we have gcc 3.0.4 running on DYNIX 4.4.2 - 4.6.1 using 2 local
        patches.

--Eric--

-----Original Message-----
From: Jason Merrill [mailto:jason@redhat.com] 
Sent: Thursday, April 25, 2002 7:51 PM
To: Janis Johnson
Cc: gcc@gcc.gnu.org
Subject: Re: patch/proposal: obsolete configurations in 3.1


>>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:

>> i?86-sequent-sysv3*
>> i?86-sequent-sysv4*
>> i?86-sequent-bsd*
>> i?86-sequent-ptx1*
>> i?86-sequent-ptx2*

> These can probably all be dropped.  Most of them are for operating
> systems that Sequent stopped supporting many years ago.

Ah, Dynix; my first work on the GNU tools was porting various bits to
i386-sequent-bsd for the CS Dept's 4-way Symmetry.  But that was a long
time ago...

Jason

Re: patch/proposal: obsolete configurations in 3.1

[Janis Johnson]

On Fri, Apr 26, 2002 at 10:37:11AM -0500, Dana, Eric wrote:
> Jason,
> 
>    Please do not remove i?86-sequent-sysv4*. We are currently using it
>    at my company. Also, I maintain the compiler for my company and will
>    sending a patch for 3.1.1 support (rather trivial).
> 
>    FYI: we have gcc 3.0.4 running on DYNIX 4.4.2 - 4.6.1 using 2 local
>         patches.
> 
> --Eric--

Eric,

When I sent the quoted mail I also said that i?86-sequent-ptx4 is still
in use, and someone pointed out that i?86-sequent-sysv4 is equivalent to
that; neither of those is being dropped.

This new mail from Jason is merely a fond reminiscence.

Janis

> 
> -----Original Message-----
> From: Jason Merrill [mailto:jason@redhat.com] 
> Sent: Thursday, April 25, 2002 7:51 PM
> To: Janis Johnson
> Cc: gcc@gcc.gnu.org
> Subject: Re: patch/proposal: obsolete configurations in 3.1
> 
> 
> >>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:
> 
> >> i?86-sequent-sysv3*
> >> i?86-sequent-sysv4*
> >> i?86-sequent-bsd*
> >> i?86-sequent-ptx1*
> >> i?86-sequent-ptx2*
> 
> > These can probably all be dropped.  Most of them are for operating
> > systems that Sequent stopped supporting many years ago.
> 
> Ah, Dynix; my first work on the GNU tools was porting various bits to
> i386-sequent-bsd for the CS Dept's 4-way Symmetry.  But that was a long
> time ago...
> 
> Jason

RE: patch/proposal: obsolete configurations in 3.1

[Dana, Eric]

Michael,

   Patches have been submitted for post GCC 3.0.4. I'm going to submit
   a patch for GCC 3.1 RSN.

--Eric--

-----Original Message-----
From: Michael Matz [mailto:matzmich@cs.tu-berlin.de] 
Sent: Tuesday, April 16, 2002 12:31 PM
To: Dana, Eric
Cc: 'gcc@gcc.gnu.org'
Subject: RE: patch/proposal: obsolete configurations in 3.1


Hi,

On Tue, 16 Apr 2002, Dana, Eric wrote:

>    i?86-sequent-sysv4*
>
>    This is still in use. We use it at my company.

And you have a newer FSF compiler than, say 2.7.2 for it?  I.e. does the
current version of GCC work for that target?  If not, do you want to make
it work?


Ciao,
Michael.

RE: patch/proposal: obsolete configurations in 3.1

[Dana, Eric]

Janis,

   i?86-sequent-sysv4*

   This is still in use. We use it at my company.

--Eric--
BMC Software Inc.


-----Original Message-----
From: Janis Johnson [mailto:janis187@us.ibm.com] 
Sent: Monday, April 15, 2002 3:46 PM
To: Zack Weinberg
Cc: Mark Mitchell; Kevin Handy; Andi Kleen; gcc@gcc.gnu.org
Subject: Re: patch/proposal: obsolete configurations in 3.1


On Mon, Apr 15, 2002 at 10:05:42AM -0700, Zack Weinberg wrote:
> 
> There are a LOT of weird proprietary-Unix m68k and i386 ports.  Would
> someone more familiar with the history care to look through this list
> and suggest more culls?
> 
> 	i?86-sequent-sysv3*
> 	i?86-sequent-sysv4*
>         i?86-sequent-bsd*
>         i?86-sequent-ptx1*
>         i?86-sequent-ptx2*

These can probably all be dropped.  Most of them are for operating
systems that Sequent stopped supporting many years ago.  The most
recent, ptx2, wasn't upgraded for Y2K changes and hasn't been
supported since.

>         i?86-sequent-ptx4*

This is still in use.

Janis
(formerly of the Sequent compiler group)

Re: patch/proposal: obsolete configurations in 3.1

['Zack Weinberg']

On Tue, Apr 16, 2002 at 10:37:49AM -0500, Dana, Eric wrote:
> Janis,
> 
>    i?86-sequent-sysv4*
> 
>    This is still in use. We use it at my company.

As far as GCC is concerned, i?86-sequent-sysv4 and i?86-sequent-ptx4
are the same thing, so don't worry, they're both staying.

(This is not to say that they ARE the same thing; only that the
differences, if any, are not significant to GCC's configuration
logic.)

zw

RE: patch/proposal: obsolete configurations in 3.1

[Michael Matz]

Hi,

On Tue, 16 Apr 2002, Dana, Eric wrote:

>    i?86-sequent-sysv4*
>
>    This is still in use. We use it at my company.

And you have a newer FSF compiler than, say 2.7.2 for it?  I.e. does the
current version of GCC work for that target?  If not, do you want to make
it work?


Ciao,
Michael.

Re: patch/proposal: obsolete configurations in 3.1

[Robert Dewar]

I agree with Mike. One of the great strengths of gcc is the great variety
of supported targets, and the ease of porting to new targets. I think the
burden should be quite high for removing a target completely. It may of
course be the case that some ports are in less good shape, but so what?

Re: patch/proposal: obsolete configurations in 3.1

[Richard Kenner]

    It seems to me that as long as a port has active maintainers that it
    is eminently reasonable to include it in the FSF GCC distribution.  If
    it doesn't have a maintainer or an active community of users, then we
    should feel no compunction about dropping it from the distribution.

I agree with that.

Re: patch/proposal: obsolete configurations in 3.1

[Robert Dewar]

Well my students are definitely using the MMIX port :-)