Remaining host configuration fragments

Remaining host configuration fragments

[Zack Weinberg]

With the patch I just posted, there are three remaining host Makefile
fragments and ten host configuration headers.  I'd like to go through
them and discuss their remaining uses.

x-interix sets X_CFLAGS (to -D__INTERIX -D_ALL_SOURCE).  It seems to
me that this should be unnecessary, but I am not familiar enough with
Interix to be sure.

m68k/x-next sets BOOT_LDFLAGS; there is a comment about needing to
make enough room for f771.  This falls into the same category as the
stage1_cflags we need for some machines - should be pushed into
configure or config.gcc.

alpha/x-vms enables building two programs and two .o files which are
not useful except on VMS.  The .o files are necessary when targeting
VMS but apparently cannot be built with GCC.  The programs translate
Unix to VMS options; I'm not sure why this is needed.  We're stuck
with this file for the time being.

The xm-headers have four general categories of things in them.

First, dinking with HOST_WIDE(ST)_INT.  This is done by
alpha/xm-alpha-interix.h, alpha/xm-vms.h, alpha/xm-vms64.h, and
i386/xm-i386-interix.h, and should be unnecessary.  hwint.h in
conjunction with the configure script is supposed to get this right
always.  I would appreciate it if the maintainers of these host
configurations would check what happens if the dinking is removed, and
contact me with detailed descriptions of any failures.

Second, adjusting PATH_SEPARATOR, DIR_SEPARATOR, DIR_SEPARATOR_2, and
HAVE_DOS_BASED_FILE_SYSTEM.  This is done by i386/xm-cygwin.h,
i386/xm-djgpp.h, i386/xm-mingw32.h, and i386/xm-vsta.h.  In canonical
form, all four of these are set as a block.  However, xm-cygwin.h does
not set PATH_SEPARATOR, and xm-vsta.h only sets PATH_SEPARATOR (why?)

I think it would be appropriate to slave the SEPARATOR macros to
HAVE_DOS_BASED_FILE_SYSTEM, and move HDBFS into xm_defines.

Third, setting HOST_OBJECT_SUFFIX and/or HOST_EXECUTABLE_SUFFIX.  This
is done by alpha/xm-vms.h, i386/xm-cygwin.h, i386/xm-djgpp.h,
i386/xm-mingw32.h, and vax/xm-vms.h.  There isn't a better place to
put these than there.

Finally, miscellaneous stuff: alpha/xm-vms.h, i386/xm-djgpp.h,
mips/xm-iris5.h, vax/xm-vms.h.  We're stuck with all of it.  Well,
arguably the irix5 and VAX VMS configurations should be scrapped.

zw

Re: Remaining host configuration fragments

[DJ Delorie]

> Second, adjusting PATH_SEPARATOR, DIR_SEPARATOR, DIR_SEPARATOR_2, and
> HAVE_DOS_BASED_FILE_SYSTEM.  This is done by i386/xm-cygwin.h,
> i386/xm-djgpp.h, i386/xm-mingw32.h, and i386/xm-vsta.h.  In canonical
> form, all four of these are set as a block.  However, xm-cygwin.h does
> not set PATH_SEPARATOR, and xm-vsta.h only sets PATH_SEPARATOR (why?)
> 
> I think it would be appropriate to slave the SEPARATOR macros to
> HAVE_DOS_BASED_FILE_SYSTEM, and move HDBFS into xm_defines.

Ideally, the src/include/filesystem.h from "over there" should be made
common to gcc, and use that.

Cygwin tries real hard to hide dos-isms, not sure if it would be OK to
have both path separators.

> Well, arguably the irix5 and VAX VMS configurations should be
> scrapped.

Why?  I've still got an irix5 machine myself...

Re: Remaining host configuration fragments

[Zack Weinberg]

On Thu, Jan 10, 2002 at 05:40:45PM -0500, DJ Delorie wrote:
> 
> Ideally, the src/include/filesystem.h from "over there" should be made
> common to gcc, and use that.

Sounds like a good idea to me.  You meant include/filenames.h, right?

> Cygwin tries real hard to hide dos-isms, not sure if it would be OK
> to have both path separators.

The point of using ; as I understand it is that : is for indicating
drive letters.  Unless Cygwin hides drive letters entirely, will :
really work as a path separator?

> > Well, arguably the irix5 and VAX VMS configurations should be
> > scrapped.
> 
> Why?  I've still got an irix5 machine myself...

I am trying to push a general principle that we should actively prune
obsolete configurations rather than leave the code around to rot
slowly and confuse people trying to do maintenance.  I picked on irix5
because it's got an xm-host header whose sole purpose is to correct a
decision autoconf gets wrong; in principle autoconf should be fixed,
but if no one uses the system anymore, we'd be better off dropping the
host configuration.

If irix5 isn't obsolete (as is demonstrated by your still using it),
then fixing the configure script might be worth it.

zw

Re: Remaining host configuration fragments

[Christopher Faylor]

On Sun, Jan 13, 2002 at 02:24:44PM -0800, Zack Weinberg wrote:
>On Thu, Jan 10, 2002 at 05:40:45PM -0500, DJ Delorie wrote:
>>Cygwin tries real hard to hide dos-isms, not sure if it would be OK to
>>have both path separators.
>
>The point of using ; as I understand it is that : is for indicating
>drive letters.  Unless Cygwin hides drive letters entirely, will :
>really work as a path separator?

Cygwin hides drive letters as much as possible.  You can't *create* a
file with a colon in it but other than a cygwin user shouldn't have to
worry about 'a:' stuff.  It uses ':' for its path separator, just like
unix.  Using anything else would confuse it.

cgf

Re: Remaining host configuration fragments

[Zack Weinberg]

On Sun, Jan 13, 2002 at 08:38:18PM -0500, Christopher Faylor wrote:
> On Sun, Jan 13, 2002 at 02:24:44PM -0800, Zack Weinberg wrote:
> >On Thu, Jan 10, 2002 at 05:40:45PM -0500, DJ Delorie wrote:
> >>Cygwin tries real hard to hide dos-isms, not sure if it would be OK to
> >>have both path separators.
> >
> >The point of using ; as I understand it is that : is for indicating
> >drive letters.  Unless Cygwin hides drive letters entirely, will :
> >really work as a path separator?
> 
> Cygwin hides drive letters as much as possible.  You can't *create* a
> file with a colon in it but other than a cygwin user shouldn't have to
> worry about 'a:' stuff.  It uses ':' for its path separator, just like
> unix.  Using anything else would confuse it.

In that case I wonder if it's appropriate to declare
HAVE_DOS_BASED_FILE_SYSTEM at all under cygwin.  GCC currently does
think it can get a drive letter in a pathname fed to it under
cygwin...

zw

Re: Remaining host configuration fragments

[DJ Delorie]

> In that case I wonder if it's appropriate to declare
> HAVE_DOS_BASED_FILE_SYSTEM at all under cygwin.  GCC currently does
> think it can get a drive letter in a pathname fed to it under
> cygwin...

Cygwin will automagically alter $PATH (and a few others) to have
posix-compliant unix-like paths, with ':' separators.  This is
transparent to the application.

However, you can pass DOS paths to gcc *as parameters* like this:

	C:\DOS> gcc c:\foo\bar.c

Cygwin will not change those for you.

So, colons in filenames are OK but colons in $PATH are separators.

Re: Remaining host configuration fragments

[DJ Delorie]

> Sounds like a good idea to me.  You meant include/filenames.h, right?

Yeah, that one.

> I am trying to push a general principle that we should actively prune
> obsolete configurations rather than leave the code around to rot
> slowly and confuse people trying to do maintenance.

I think we should adopt something like gdb's policy - obsoletions
should be publically announced well in advance, noted in release X,
deprecated in release X+1, and removed in release X+2.

Otherwise, you risk obsoleting a platform that has a silent but
non-zero user base.

Re: Remaining host configuration fragments

[Mark Mitchell]

> I am trying to push a general principle that we should actively prune
> obsolete configurations rather than leave the code around to rot
> slowly and confuse people trying to do maintenance.

Yes.

In contrast with some other folks, I would even be willing to say
something like this: "Even though we know there are people out there
who still use Irix 5, we are dropping support for it in GCC 3.1.
You can still use GCC 3.0 (or earlier) there, of course."

In some cases, we are still trying to support systems with GCC that
the operating system vendors stopped supporting years ago.  To me,
this is not an optimal use of scarce resources.

I don't have any good bright-line criteria for making that decision,
though.

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

Re: Remaining host configuration fragments

[Eric Christopher]

> In contrast with some other folks, I would even be willing to say
> something like this: "Even though we know there are people out there who
> still use Irix 5, we are dropping support for it in GCC 3.1. You can
> still use GCC 3.0 (or earlier) there, of course."

Speaking of which - what do you think would be a good way of announcing
this sort of thing? I've got a load of old obsolete platforms in mips and
I'd like to lose all of them :)

I'm to the point of keeping irix6+, linux, and the embeddeds if no one
can come up with a good reason. (I think this gets me elf only too...)

-eric

-- 
I will not use abbrev.

Re: Remaining host configuration fragments

[Gerald Pfeifer]

On Wed, 16 Jan 2002, Eric Christopher wrote:
>> In contrast with some other folks, I would even be willing to say
>> something like this: "Even though we know there are people out there who
>> still use Irix 5, we are dropping support for it in GCC 3.1. You can
>> still use GCC 3.0 (or earlier) there, of course."
> Speaking of which - what do you think would be a good way of announcing
> this sort of thing? I've got a load of old obsolete platforms in mips and
> I'd like to lose all of them :)

In any case, send a message (with appropriate subject that makes the
situation clear to someone just browsing subjects) to gcc@gcc.gnu.org.

If it's a more substantial change, also send the announcement to
gcc-announce@gcc.gnu.org.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Remaining host configuration fragments

[Paul Koning]

>>>>> "Eric" == Eric Christopher <echristo@redhat.com> writes:

 >> In contrast with some other folks, I would even be willing to say
 >> something like this: "Even though we know there are people out
 >> there who still use Irix 5, we are dropping support for it in GCC
 >> 3.1. You can still use GCC 3.0 (or earlier) there, of course."

 Eric> Speaking of which - what do you think would be a good way of
 Eric> announcing this sort of thing? I've got a load of old obsolete
 Eric> platforms in mips and I'd like to lose all of them :)

 Eric> I'm to the point of keeping irix6+, linux, and the embeddeds if
 Eric> no one can come up with a good reason. (I think this gets me
 Eric> elf only too...)

NetBSD is needed also...

       paul

Re: Remaining host configuration fragments

[Eric Christopher]

> 
> NetBSD is needed also...

Thanks. I remembered that when I saw thorpej's patch. :)

-eric

-- 
I will not use abbrev.

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Tue, 15 Jan 2002, Mark Mitchell wrote:

> In some cases, we are still trying to support systems with GCC that
> the operating system vendors stopped supporting years ago.  To me,
> this is not an optimal use of scarce resources.

Host and target support are fairly independent here.  Also, supporting
bootstrapping from the native compiler is separate from supporting
bootstrapping with a previous GCC.  (Are there current systems for which
the native compiler is still only K&R?)

We really ought to try to maintain proper lists of systems for which
support is dropped, to include in the caveats lists for each new release;
as is target maintainers just drop those they judge obsolete, without
detailed documentation.

> I don't have any good bright-line criteria for making that decision,
> though.

I've suggested the test of whether Y2K fixes were provided for that
operating system version as some indication of whether it is at all
maintained in recent years.  Other criteria might be whether it is the 
last version of that operating system supported by some hardware, and 
whether any build success or failure reports have been made for that 
system with GCC 3.0 or 2.95.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[DJ Delorie]

> In contrast with some other folks, I would even be willing to say
> something like this: "Even though we know there are people out there
> who still use Irix 5, we are dropping support for it in GCC 3.1.
> You can still use GCC 3.0 (or earlier) there, of course."

Like all other gcc features, we need at least one release where it
exists but is deprecated, perhaps with a warning printed for each gcc
invocation.  Support for a host shouldn't go from "works" to "missing"
in one step - then someone willing to support it has no chance of
volunteering until it's too late.

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, DJ Delorie wrote:

> invocation.  Support for a host shouldn't go from "works" to "missing"
> in one step - then someone willing to support it has no chance of
> volunteering until it's too late.

It generally goes "works" --> bitrotten (for several releases) -->
"missing" in practice.  People can always volunteer to add back and
maintain support for a desupported host or target, getting the last
version of support files from CVS.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[DJ Delorie]

> It generally goes "works" --> bitrotten (for several releases) -->
> "missing" in practice.  People can always volunteer to add back and
> maintain support for a desupported host or target, getting the last
> version of support files from CVS.

Bitrotting is a poor way to officially obsolete a host or target.  I
would suggest modifying config.gcc to support a two-step obsolescence:

1. Deprecate.

$ ./configure
Warning: mips-foo-bar is deprecated and will be removed in a future
release.
Use --enable-deprecated-configs to build it anyway.
... stops ...

$ ./configure --enable-deprecated-configs
Warning: mips-foo-bar is deprecated and will be removed in a future
release.
... continues ...

2. Obsolete.

$ ./configure
Error: target mips-foo-bar is obsolete.  If you wish to re-add support
for this target, you may volunteer to do so.
... stops ...

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, DJ Delorie wrote:

> Bitrotting is a poor way to officially obsolete a host or target.  I
> would suggest modifying config.gcc to support a two-step obsolescence:

But with this method, the hosts and targets we deprecate will probably be
bitrotten anyway.  Without having machines or simulators for every
supported host and target, we can't meaningfully have a state of
deprecated but supported which means anything much.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[DJ Delorie]

> But with this method, the hosts and targets we deprecate will probably be
> bitrotten anyway.  Without having machines or simulators for every
> supported host and target, we can't meaningfully have a state of
> deprecated but supported which means anything much.

We can tailor the message suitably.  What I'm saying is that before we
*actively* remove a host/target (regardless of the reason), we should
warn everyone.  This is different than trying to deduce which targets
have bitrotted that we otherwise don't know about.

In this case, Zack is (was?) removing files needed for irix5, without
advance warning.  Regardless of how bitrotted irix5 is, we should give
the users fair warning.

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, DJ Delorie wrote:

> We can tailor the message suitably.  What I'm saying is that before we
> *actively* remove a host/target (regardless of the reason), we should
> warn everyone.  This is different than trying to deduce which targets
> have bitrotted that we otherwise don't know about.

That warning can be done by a message to gcc-announce (as was done when
the architectures that had never been supported in GCC 2 were removed)  
inviting people with a use for the targets to say so.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[Zack Weinberg]

On Wed, Jan 16, 2002 at 02:42:18PM -0500, DJ Delorie wrote:
> 
> In this case, Zack is (was?) removing files needed for irix5, without
> advance warning.  Regardless of how bitrotted irix5 is, we should give
> the users fair warning.

I didn't touch the irix5 port, I merely suggested it as a candidate
for removal.

zw

Re: Remaining host configuration fragments

[DJ Delorie]

> I didn't touch the irix5 port, I merely suggested it as a candidate
> for removal.

Do you have an off-the-top-of-your-head estimate of how bitrotten it
is, and how much work would bring it back?

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, DJ Delorie wrote:

> > I didn't touch the irix5 port, I merely suggested it as a candidate
> > for removal.
> 
> Do you have an off-the-top-of-your-head estimate of how bitrotten it
> is, and how much work would bring it back?

In any case, isn't irix4 a more likely candidate for removal?

Remember if removing support for a system to remove all the docs for it,
including in install.texi and trouble.texi.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[Eric Christopher]

In article <200201162029.g0GKTQU22719@greed.delorie.com>, "DJ Delorie"
<dj@redhat.com> wrote:

>> I didn't touch the irix5 port, I merely suggested it as a candidate for
>> removal.
> 
> Do you have an off-the-top-of-your-head estimate of how bitrotten it is,
> and how much work would bring it back?

I don't _know_ that it's actually been built in at least a year. Probably
more.

You could try it... :) I, however, want to get rid of most non-elf
configs in mips. If someone comes up with a pe port, for example, I'm
willing to keep coff support around for that.

I just can't come up with a good logic for keeping around say the Sony
News system, or an irix so old it wasn't called irix ;)

-eric

-- 
I will not use abbrev.

Re: Remaining host configuration fragments

[Rainer Orth]

"Eric Christopher" <echristo@redhat.com> writes:

> > Do you have an off-the-top-of-your-head estimate of how bitrotten it is,
> > and how much work would bring it back?
> 
> I don't _know_ that it's actually been built in at least a year. Probably
> more.

I built the mips-sgi-irix5 configuration on IRIX 6 last year, which is
necessary if you want to get O32 ABI support.  It worked after working
around a gas problem (acked, but not yet checked into binutils).  There
were a couple of problems in exception handling, which I believe have been
fixed since.  I didn't have time to work on gcc recently, but hope to
revive this configuration at some time (or even to complete older patches
of mine to integrate O32 support into the IRIX 6 config).

> You could try it... :) I, however, want to get rid of most non-elf
> configs in mips. If someone comes up with a pe port, for example, I'm
> willing to keep coff support around for that.

But the IRIX 5 configuration *is* an ELF target, it only doesn't use DWARF 2
but stabs (or mdebug if someone would lift the support from the
alpha-dec-osf config).

	Rainer

Re: Remaining host configuration fragments

[Joe Buck]

> > It generally goes "works" --> bitrotten (for several releases) -->
> > "missing" in practice.  People can always volunteer to add back and
> > maintain support for a desupported host or target, getting the last
> > version of support files from CVS.

DJ Delorie writes:
> Bitrotting is a poor way to officially obsolete a host or target.

Unfortunately, it's hard to avoid, unless we mark the vast majority of
platforms deprecated because no one sent us a test result during
development.

Re: Remaining host configuration fragments

[Zack Weinberg]

On Tue, Jan 15, 2002 at 11:05:17PM -0800, Mark Mitchell wrote:
> 
> In some cases, we are still trying to support systems with GCC that
> the operating system vendors stopped supporting years ago.  To me,
> this is not an optimal use of scarce resources.
> 
> I don't have any good bright-line criteria for making that decision,
> though.

Some candidates for dropping:

Architectures which don't support ELF.
Architectures which were never updated to new varargs.
All configurations based on SVR3 or earlier.
All configurations based on 4.3BSD or earlier.
All configurations based on COFF.

It is not easy to enumerate these.  For the first one, I have a list:

  1750a  c4x      convex   elxsi  ns32k  romp  we32k
  a29k   clipper  dsp16xx  i960   pdp11  vax

(vax is actively maintained, so it could be an exception.)

zw

Re: Remaining host configuration fragments

[DJ Delorie]

> All configurations based on COFF.

Um, djgpp, cygwin, and mingw all use COFF.  Please don't blindly
delete those ;-)

Re: Remaining host configuration fragments

[Robert Lipe]

Zack Weinberg wrote:

> Some candidates for dropping:

[ Numbers added ] 

> 1. Architectures which don't support ELF.
> 2. Architectures which were never updated to new varargs.
> 3. All configurations based on SVR3 or earlier.
> 4. All configurations based on 4.3BSD or earlier.
> 5. All configurations based on COFF.

#1 and #5 are somewhat related.   
For #3, there are active SVR3 systems that support ELF.  (Yes, I know it
  sounds anachronistic.)

> It is not easy to enumerate these.  For the first one, I have a list:
> 
>   1750a  c4x      convex   elxsi  ns32k  romp  we32k
>   a29k   clipper  dsp16xx  i960   pdp11  vax

The embedded guys might still care about i960.  Roaming through
ChangeLogs, it looks more active than most of that list.

I do applaud your goal of pruning dead code.  

RJL

Re: Remaining host configuration fragments

[Tim Prince]

Robert Lipe wrote:

> Zack Weinberg wrote:
> 
> 
>>Some candidates for dropping:
>>
> 
> [ Numbers added ] 
> 
> 
>>1. Architectures which don't support ELF.
>>2. Architectures which were never updated to new varargs.
>>3. All configurations based on SVR3 or earlier.
>>4. All configurations based on 4.3BSD or earlier.
>>5. All configurations based on COFF.
>>
> 
> #1 and #5 are somewhat related.   
> For #3, there are active SVR3 systems that support ELF.  (Yes, I know it
>   sounds anachronistic.)
> 
> 
>>It is not easy to enumerate these.  For the first one, I have a list:
>>
>>  1750a  c4x      convex   elxsi  ns32k  romp  we32k
>>  a29k   clipper  dsp16xx  i960   pdp11  vax
>>
> 
> The embedded guys might still care about i960.  Roaming through
> ChangeLogs, it looks more active than most of that list.
> 
> I do applaud your goal of pruning dead code.  
> 
> RJL
> 
> 

Are you looking for more people to post their weekly test-results to 
prove activity on coff configurations?  I don't believe cygwin supports 
ELF; I'm sure Bill Gates would approve of withdrawing gcc support, but 
it appears more active than many others, and more of us could post 
test-results if that helps.

-- 
Tim Prince
tprince@computer.org

Re: Remaining host configuration fragments

[Paul Koning]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

 Zack> On Tue, Jan 15, 2002 at 11:05:17PM -0800, Mark Mitchell wrote:
 >>  In some cases, we are still trying to support systems with GCC
 >> that the operating system vendors stopped supporting years ago.
 >> To me, this is not an optimal use of scarce resources.
 >> 
 >> I don't have any good bright-line criteria for making that
 >> decision, though.

 Zack> Some candidates for dropping:

 Zack> Architectures which don't support ELF.  Architectures which
 Zack> were never updated to new varargs.  All configurations based on
 Zack> SVR3 or earlier.  All configurations based on 4.3BSD or
 Zack> earlier.  All configurations based on COFF.

 Zack> It is not easy to enumerate these.  For the first one, I have a
 Zack> list:

 Zack> 1750a c4x convex elxsi ns32k romp we32k a29k clipper dsp16xx
 Zack> i960 pdp11 vax

Isn't c4x only about 2 years old?  I haven't used it yet, but a free
software compiler for popular DSP chips would be a very good thing
indeed.   That would cover the dsp16xx as well.

It doesn't seem so strange that they don't support ELF, given that a
DSP application is often just a single chunk of code that completely
owns the machine, no traces of an OS anywhere.

     paul

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, Zack Weinberg wrote:

>   1750a  c4x      convex   elxsi  ns32k  romp  we32k
>   a29k   clipper  dsp16xx  i960   pdp11  vax

NetBSD supports vax and ns32k.  I think NetBSD/vax supports ELF.  2.11BSD
for pdp11 is still actively maintained and PDP-11 hardware is available
from Mentec.  dsp16xx has a maintainer (Michael Collison) even though he
hasn't added himself to MAINTAINERS.  I think elxsi has been suggested as
the one of the above most likely to be obsolete.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[Jason R Thorpe]

On Wed, Jan 16, 2002 at 10:12:33PM +0000, Joseph S. Myers wrote:

 > NetBSD supports vax and ns32k.  I think NetBSD/vax supports ELF.  2.11BSD

Yes, NetBSD/vax supports ELF, but the author of the changes hasn't submitted
them to the master sources yet (he has one more bug to squash, and then has
to do the paperwork dance).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: Remaining host configuration fragments

[Lars Brinkhoff]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> On Wed, 16 Jan 2002, Zack Weinberg wrote:
> >   [...] pdp11 [...]
> 2.11BSD for pdp11 is still actively maintained and PDP-11 hardware
> is available from Mentec.

I asked in three places whether anyone was using GCC to compile code
for the PDP-11: the PDP Unix Preservation Society mailing list (where
the 2.11BSD maintainer lurks), the classiccmp mailing list, and the
alt.sys.pdp11 newsgroup.  In all cases, there were no voices raised in
defense of the PDP-11 back end in GCC.

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

Re: Remaining host configuration fragments

[Paul Koning]

>>>>> "Lars" == Lars Brinkhoff <lars.spam@nocrew.org> writes:

 Lars> "Joseph S. Myers" <jsm28@cam.ac.uk> writes:
 >> On Wed, 16 Jan 2002, Zack Weinberg wrote: > [...] pdp11 [...]
 >> 2.11BSD for pdp11 is still actively maintained and PDP-11 hardware
 >> is available from Mentec.

 Lars> I asked in three places whether anyone was using GCC to compile
 Lars> code for the PDP-11: the PDP Unix Preservation Society mailing
 Lars> list (where the 2.11BSD maintainer lurks), the classiccmp
 Lars> mailing list, and the alt.sys.pdp11 newsgroup.  In all cases,
 Lars> there were no voices raised in defense of the PDP-11 back end
 Lars> in GCC.

Perhaps that's because the backend in its current state doesn't
actually work.  I've been tinkering with it (inspired by the new pdp11
GAS support).  It's getting closer.

If no one else cares, I can certainly treat it as a private amusement
and do nothing further with it, but if I make decent progress I'm
certainly willing to contribute it.

	  paul

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Tue, 22 Jan 2002, Paul Koning wrote:

> Perhaps that's because the backend in its current state doesn't
> actually work.  I've been tinkering with it (inspired by the new pdp11
> GAS support).  It's getting closer.

It certainly didn't work before 2.95 (the first release with some of my
fixes to it in) since before those fixes it was outputting constants in
decimal, and AFAIK all PDP-11 assemblers expect constants in octal.  (Nor
did the assembler syntax then correspond to what the 2.11BSD assembler
expects.)  I made it at least produce passable output that could be
assembled under 2.11BSD, but I'd expect that it still didn't work at all
well.

> If no one else cares, I can certainly treat it as a private amusement
> and do nothing further with it, but if I make decent progress I'm
> certainly willing to contribute it.

I'd be glad to see further fixes to make it actually work properly go into
GCC.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[law]

 In message <15437.47483.469309.531061@pkoning.dev.equallogic.com>, Paul 
Koning
writes:
 >  Lars> I asked in three places whether anyone was using GCC to compile
 >  Lars> code for the PDP-11: the PDP Unix Preservation Society mailing
 >  Lars> list (where the 2.11BSD maintainer lurks), the classiccmp
 >  Lars> mailing list, and the alt.sys.pdp11 newsgroup.  In all cases,
 >  Lars> there were no voices raised in defense of the PDP-11 back end
 >  Lars> in GCC.
 > 
 > Perhaps that's because the backend in its current state doesn't
 > actually work.  I've been tinkering with it (inspired by the new pdp11
 > GAS support).  It's getting closer.
 > 
 > If no one else cares, I can certainly treat it as a private amusement
 > and do nothing further with it, but if I make decent progress I'm
 > certainly willing to contribute it.
I certainly don't see the PDP11 backend as strategic, but as long as folks
are actively trying to improve it's state we should continue to try and
keep it from breaking any worse than it already is.

jeff

Re: Remaining host configuration fragments

[Joe Buck]

> On Tue, Jan 15, 2002 at 11:05:17PM -0800, Mark Mitchell wrote:
> > 
> > In some cases, we are still trying to support systems with GCC that
> > the operating system vendors stopped supporting years ago.  To me,
> > this is not an optimal use of scarce resources.
> > 
> > I don't have any good bright-line criteria for making that decision,
> > though.

Zack writes:
> Some candidates for dropping:
> 
> Architectures which don't support ELF.
> Architectures which were never updated to new varargs.
> All configurations based on SVR3 or earlier.
> All configurations based on 4.3BSD or earlier.
> All configurations based on COFF.

These criteria are way too severe, IMHO.

> It is not easy to enumerate these.  For the first one, I have a list:
> 
>   1750a  c4x      convex   elxsi  ns32k  romp  we32k
>   a29k   clipper  dsp16xx  i960   pdp11  vax
> 
> (vax is actively maintained, so it could be an exception.)

c4x is being actively maintained; I see that Michael Hayes has
made some fixes in the last seven days.  Similarly dsp16xx seems
to be getting maintainance.  Both are DSP targets for chips that
are still in wide use.

On the other hand, I seem to recall that the world's last elxsi was
turned off some time ago.

Re: Remaining host configuration fragments

[Stan Shebs]

Mark Mitchell wrote:
> 
> In contrast with some other folks, I would even be willing to say
> something like this: "Even though we know there are people out there
> who still use Irix 5, we are dropping support for it in GCC 3.1.
> You can still use GCC 3.0 (or earlier) there, of course."
> 
> In some cases, we are still trying to support systems with GCC that
> the operating system vendors stopped supporting years ago.  To me,
> this is not an optimal use of scarce resources.

Heh, we at least ought to offer to take users' money before
declaring that the resources are scarce.

Or to make it sound less crass :-), one of the purposes of
announcing the obsolescence of a configuration is to give
users a chance to consider whether they care enough to come up
with time or money or both to keep a configuration alive.  Even
something as silly-sounding as retrocomputing could be a useful
hook to get somebody involved with GCC, who may then expand to
working on more than just the one oddball config.

The purpose of announcing widely, and as part of a release, is
because GCC releases go much further into the world than messages
on a single mailing list.  An obsolescence announcement in a
release is a wakeup call to people that may have been using a
config without being aware of its impending doom; if the config
is simply gone from a release, then it looks like we're just making
arbitrary decisions without talking to users, which discourages our
potential contributors before they even get a chance to speak up.

Stan

Re: Remaining host configuration fragments

[Toon Moene]

Stan Shebs wrote:

> Mark Mitchell wrote:

> > In contrast with some other folks, I would even be willing to say
> > something like this: "Even though we know there are people out there
> > who still use Irix 5, we are dropping support for it in GCC 3.1.
> > You can still use GCC 3.0 (or earlier) there, of course."

> Heh, we at least ought to offer to take users' money before
> declaring that the resources are scarce.

It would be really interesting to try Mark's algorithm on front-ends. 
Strictly speaking, the Fortran front-end is obsolete by more than a
decade, now :-)

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Remaining host configuration fragments

[Bernard Dautrevaux]

> -----Original Message-----
> From: DJ Delorie [mailto:dj@redhat.com]
> Sent: Monday, January 14, 2002 10:50 PM
> To: zack@codesourcery.com
> Cc: gcc@gcc.gnu.org
> Subject: Re: Remaining host configuration fragments
> 
> 
> 
> > In that case I wonder if it's appropriate to declare
> > HAVE_DOS_BASED_FILE_SYSTEM at all under cygwin.  GCC currently does
> > think it can get a drive letter in a pathname fed to it under
> > cygwin...
> 
> Cygwin will automagically alter $PATH (and a few others) to have
> posix-compliant unix-like paths, with ':' separators.  This is
> transparent to the application.
> 
> However, you can pass DOS paths to gcc *as parameters* like this:
> 
> 	C:\DOS> gcc c:\foo\bar.c
> 
> Cygwin will not change those for you.
> 
> So, colons in filenames are OK but colons in $PATH are separators.
> 

Note that there you call GCC from CMD.exe, so you should get a WINDOWS (i.e.
';' separated) PATH, not a cygwin one. However you can also have:

bash$ gcc c:\\foo\\bar.c

or

bash$ gcc c:/foo/bar.c

and in both cases you get a DOS-like filename argument (with drive letter)
while the PATH is ':'-separated; all this is a bit complicated ;-)

However the initial call (from CMD.exe) is not the standard way to invoke
gcc in the cygwin environment; it's rather the correct way to invoke a
mingw32-hosted gcc (and in that case all DOS conventions should be obeyed)
so cygwin-hosted gcc may well only expect a ':' separated PATH.

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Remaining host configuration fragments

[DJ Delorie]

> Note that there you call GCC from CMD.exe, so you should get a
> WINDOWS (i.e.  ';' separated) PATH, not a cygwin one.

Cygwin fixes $PATH anyway in that case.

> However the initial call (from CMD.exe) is not the standard way to
> invoke gcc in the cygwin environment;

There's nothing wrong with invoking gcc from cmd.exe.  Red Hat's
customers do it all the time with cygwin-hosted cross compilers.

Re: Remaining host configuration fragments

[mike stump]

> From: Joe Buck <jbuck@synopsys.COM>
> To: dj@redhat.com (DJ Delorie)
> Date: Wed, 16 Jan 2002 11:25:12 -0800 (PST)
> Cc: jsm28@cam.ac.uk, gcc@gcc.gnu.org, dj@redhat.com

> Unfortunately, it's hard to avoid, unless we mark the vast majority
> of platforms deprecated because no one sent us a test result during
> development.

A gcc that only supports 6 platforms, and nothing else isn't what we
should sign up for.  This would be bad.  Making a decision that
ultimately results in this outcome, is also bad and I am against it.

I'd rather deprecate because we believe that no machines exist in
production or near production use on the planet, not because of a lack
of testcase submittal.  Go count the number of platforms submitted in
http://gcc.gnu.org/gcc-3.0/buildstat.html.  There aren't many.

Bitrotting is fine.  Everything bitrots.  It is a natural state of
affairs.  As the code matures, the incident rate of bitrotting should
decrease.  A slightly bitrotted port is usually fairly easy to get
going again.

It is when we don't expect it is useful to get a port going again,
that it might be beneficial to remove it.

IBM-RT I think is finally dead.  Quick, bonus points if someone can
even name the chip in it.  Kenner, you don't get to play (I think you
wrote it).

Likewise any OS that hasn't had a new release in 5 years.  These are
likely to not be worthwhile to preserve.

Re: Remaining host configuration fragments

[Jason R Thorpe]

On Wed, Jan 16, 2002 at 06:52:54PM -0800, mike stump wrote:

 > IBM-RT I think is finally dead.  Quick, bonus points if someone can
 > even name the chip in it.  Kenner, you don't get to play (I think you
 > wrote it).

ROMP!  Now, let's see if I can remember which model included which
FPU... :-)

There are some hobbyists out there who care about the ROMP, but if they
want to, they can always resurrect the port...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>
	...glancing at the sad-looking 6151/135 in the corner
	of the room...

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Wed, 16 Jan 2002, Jason R Thorpe wrote:

> ROMP!  Now, let's see if I can remember which model included which
> FPU... :-)
> 
> There are some hobbyists out there who care about the ROMP, but if they
> want to, they can always resurrect the port...

Post to classiccmp seeking volunteers (with hardware) to maintain this and
other old ports (or indeed resurrect the ports never updated for GCC 2, if
they want something harder to do)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[DJ Delorie]

> Likewise any OS that hasn't had a new release in 5 years.  These are
> likely to not be worthwhile to preserve.

DJGPP runs on ms-dos.  There hasn't been a release for that in, what,
decades?  It still gets a thousand new users a day.

IMHO a platform should be deprecated iff it meets all these:

1. Platform not supported by manufacturer for N years
2. No volunteers to maintain the port
3. Known not to function for the last N minor releases (2.95, 3.0, 3.1)
4. Nobody notices #3 :-)

I like GDB's method - they annotate deprecated files so you get
compile errors if you try to use them, and the annotations tell you
what to do to resurrect the platform.  Again, we should try to get
people to participate, rather than annoying them.

Re: Remaining host configuration fragments

[Alexandre Oliva]

On Jan 17, 2002, DJ Delorie <dj@redhat.com> wrote:

>> Likewise any OS that hasn't had a new release in 5 years.  These are
>> likely to not be worthwhile to preserve.

> DJGPP runs on ms-dos.  There hasn't been a release for that in, what,
> decades?  It still gets a thousand new users a day.

But FreeDOS was still being actively developed, last time I looked.  I
though most of DJGPP's user base comes from that these days.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Remaining host configuration fragments

[DJ Delorie]

> But FreeDOS was still being actively developed, last time I looked.  I
> though most of DJGPP's user base comes from that these days.

Yeah, and windows and dosemu.

Re: Remaining host configuration fragments

[Paul Koning]

>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:

 >> Likewise any OS that hasn't had a new release in 5 years.  These
 >> are likely to not be worthwhile to preserve.

 DJ> DJGPP runs on ms-dos.  There hasn't been a release for that in,
 DJ> what, decades?  It still gets a thousand new users a day.

 DJ> IMHO a platform should be deprecated iff it meets all these:

 DJ> 1. Platform not supported by manufacturer for N years 2. No
 DJ> volunteers to maintain the port 3. Known not to function for the
 DJ> last N minor releases (2.95, 3.0, 3.1) 4. Nobody notices #3 :-)

I like that approach.

For one thing, it accommodates oddball platforms.  To pick one
example, it would allow pdp11 to continue to exist as a target if
someone will maintain it.  (I don't know if Mike G. still considers
himself to be the one; if not, I'm thinking that perhaps I might
volunteer.)  As someone else mentioned, there's "retrocomputing" and
there are hobbyists that use surprising platforms; neither of those is
mainstream, and neither warrants a lot of work, but if the volunteers
are there, it's hard to argue why the stuff should be deleted.

      paul

Re: Remaining host configuration fragments

[mike stump]

> Date: Wed, 16 Jan 2002 15:49:48 -0600
> From: Robert Lipe <robertlipe@usa.net>
> To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>

> The embedded guys might still care about i960.

Our take, i960 is basically dead.  Sure, there are folks that have it,
that use it, that are using older releases, and might need support for
it, but they probably don't want a new release for it.  We've removed
it from our releases.

Re: Remaining host configuration fragments

[Eric Christopher]

> Our take, i960 is basically dead.  Sure, there are folks that have it,
> that use it, that are using older releases, and might need support for
> it, but they probably don't want a new release for it.  We've removed it
> from our releases.

Stunningly I've seen someone using it recently...

-eric

-- 
I will not use abbrev.

Re: Remaining host configuration fragments

[Geoff Keating]

mike stump <mrs@windriver.com> writes:

> > Date: Wed, 16 Jan 2002 15:49:48 -0600
> > From: Robert Lipe <robertlipe@usa.net>
> > To: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
> 
> > The embedded guys might still care about i960.
> 
> Our take, i960 is basically dead.  Sure, there are folks that have it,
> that use it, that are using older releases, and might need support for
> it, but they probably don't want a new release for it.  We've removed
> it from our releases.

We still have customers for it.  These are probably the same people
that are using your older releases :-).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: Remaining host configuration fragments

[mike stump]

> Date: Wed, 16 Jan 2002 22:12:33 +0000 (GMT)
> From: "Joseph S. Myers" <jsm28@cam.ac.uk>
> To: Zack Weinberg <zack@codesourcery.com>

> I think elxsi has been suggested as the one of the above most likely
> to be obsolete.

It can go.  Last hardware built around 87 maybe.  Company defunct soon
after.  A decade to wash the machines out of the pipeline.  Wait 5
years, time to remove.

Re: Remaining host configuration fragments

[Richard Kenner]

    A gcc that only supports 6 platforms, and nothing else isn't what we
    should sign up for.  This would be bad.  Making a decision that
    ultimately results in this outcome, is also bad and I am against it.

I agree.

The major point of GCC is its diversity: that it runs on every machine.
Agressively removing targets would greatly diminish that.

    Bitrotting is fine.  Everything bitrots.  It is a natural state of
    affairs.  As the code matures, the incident rate of bitrotting should
    decrease.  A slightly bitrotted port is usually fairly easy to get
    going again.

Agreed.

    IBM-RT I think is finally dead.  Quick, bonus points if someone can
    even name the chip in it.  Kenner, you don't get to play (I think you
    wrote it).

I did.  Not only that, I still use the machine every day, though I don't
use GCC or any other development tool on it.

    Likewise any OS that hasn't had a new release in 5 years.  These are
    likely to not be worthwhile to preserve.

Maybe yes, maybe no.  People still use old machines.

Re: Remaining host configuration fragments

[Richard Kenner]

    IMHO a platform should be deprecated iff it meets all these:

    1. Platform not supported by manufacturer for N years
    2. No volunteers to maintain the port
    3. Known not to function for the last N minor releases (2.95, 3.0, 3.1)
    4. Nobody notices #3 :-)

Of course, if #4 is true, the first part of #3 can't be, but basically
I agree with a very strict criteria like this.

And even then, I don't recommend actually *removing* the files, just
not documenting it as a supported port.  There is great historical value
in these files and people shouldn't have to find old releases to see them.

Re: Remaining host configuration fragments

[DJ Delorie]

>     3. Known not to function for the last N minor releases (2.95, 3.0, 3.1)
>     4. Nobody notices #3 :-)
> 
> Of course, if #4 is true, the first part of #3 can't be, but basically
> I agree with a very strict criteria like this.

In this case, if Zack now determines that irix5 hasn't worked since
before 2.95, I think 3 and 4 would be satisfied.  Perhaps #4 should
read "noticed" instead of "notices" ;-)

#3 is void if, say, it worked as recently as two releases ago.
#4 is void if, say, people have complained about it not working.

> And even then, I don't recommend actually *removing* the files, just
> not documenting it as a supported port.  There is great historical value
> in these files and people shouldn't have to find old releases to see them.

Again, I like the idea of adding a syntaxically erroneous comment to
such files.  It keeps the history, encourages volunteerism, sets
proper expectations, yet prevents the platform from being used while
it is in a known unusable state.

Re: Remaining host configuration fragments

[Phil Blundell]

On Thu, 2002-01-17 at 15:17, DJ Delorie wrote:
> Again, I like the idea of adding a syntaxically erroneous comment to
> such files.  It keeps the history, encourages volunteerism, sets
> proper expectations, yet prevents the platform from being used while
> it is in a known unusable state.

Seems like a good plan.

The way glibc deals with this is to have the configure script abort if
you are configuring for a platform that's known not to work, either
because the support was never written or because it's become
bit-rotted.  You can configure with a special "--disable-sanity-checks"
argument if you want to try your luck by building it anyway, but this
seems quite successful at communicating to casual users that they
shouldn't expect too much.

p.

Re: Remaining host configuration fragments

[Joe Buck]

Kenner writes:
>     IMHO a platform should be deprecated iff it meets all these:
> 
>     1. Platform not supported by manufacturer for N years
>     2. No volunteers to maintain the port
>     3. Known not to function for the last N minor releases (2.95, 3.0, 3.1)
>     4. Nobody notices #3 :-)
> 
> Of course, if #4 is true, the first part of #3 can't be, but basically
> I agree with a very strict criteria like this.

I like the general thrust of this proposal.

To make it consistent, just change #4 to "There are no users of the
platform who have complained in the last [time period]".

If a gcc developer notices, or someone finds out while just diddling
around but has no need for gcc on that platform, that wouldn't count.

> And even then, I don't recommend actually *removing* the files, just
> not documenting it as a supported port.  There is great historical value
> in these files and people shouldn't have to find old releases to see them.

I think one reason why many gcc developers have been asking for a more
aggressive deprecation policy is that when there is a change to some
facility that backends use, all the backends must be fixed or (in at
least some cases) they don't even compile.  One possibility would be
to create a subdirectory of gcc/config where the deprecated stuff would
live, and developers would no longer be asked to keep it current.

Re: Remaining host configuration fragments

[Stan Shebs]

Joe Buck wrote:
> 
> > And even then, I don't recommend actually *removing* the files, just
> > not documenting it as a supported port.  There is great historical value
> > in these files and people shouldn't have to find old releases to see them.
> 
> I think one reason why many gcc developers have been asking for a more
> aggressive deprecation policy is that when there is a change to some
> facility that backends use, all the backends must be fixed or (in at
> least some cases) they don't even compile.  One possibility would be
> to create a subdirectory of gcc/config where the deprecated stuff would
> live, and developers would no longer be asked to keep it current.

When I went around on this with RMS for GDB, he agreed that it was
reasonable to "mark files as obsolete".  So I did a little script
that added the strings "/* OBSOLETE " and "*/" to the beginning
and end of every line of the file (and escaped comments within
lines, duh).  This both gets the point across to current developers
(and to any automated tools that browse source files), and leaves
everything exactly in place, so that the future would-be reviver
can recover the config from the last release before final deletion,
simply by reverting the edits.

GDB has been doing this for a couple years now, and so far the
trip to obsolescence has always been one-way.

Stan

Re: Remaining host configuration fragments

[Joseph S. Myers]

On Thu, 17 Jan 2002, Stan Shebs wrote:

> (and to any automated tools that browse source files), and leaves
> everything exactly in place, so that the future would-be reviver
> can recover the config from the last release before final deletion,
> simply by reverting the edits.

People can recover the files from the last pre-deletion revisions in CVS -
and should do so, rather than using a release, given that global changes
(obsoleting a target macro, etc.) are applied across all relevant targets,
obsolete or otherwise, so a version in a release will not be a final
version.  Given CVS, doing edits to the files before deleting them seems
pointless - as those edits make the target non-buildable in that release,
why not simply document that the target is obsolete and that certain files
should be retrieved from CVS to attempt to build it (along with a URL for
the patch that removed the target, to give information about any other
associated changes that might need reverting)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Remaining host configuration fragments

[Joe Buck]

[ marking files as obsolete ]

Stan Shebs writes:
> When I went around on this with RMS for GDB, he agreed that it was
> reasonable to "mark files as obsolete".  So I did a little script
> that added the strings "/* OBSOLETE " and "*/" to the beginning
> and end of every line of the file (and escaped comments within
> lines, duh).

It seems that something like

#ifndef TRY_TO_COMPILE_THIS_FILE_EVEN_THOUGH_IT_IS_OBSOLETE
...
#endif

:-)

would be simpler (no need to worry about nesting of comments).

Re: Remaining host configuration fragments

[DJ Delorie]

> would be simpler (no need to worry about nesting of comments).

If the idea is to keep users from using the file, why do we need to
worry about nesting of comments?  Just throw a chunk of uncommented
English text at the top of the file and let it fail.

Re: Remaining host configuration fragments

[Stan Shebs]

DJ Delorie wrote:
> 
> > would be simpler (no need to worry about nesting of comments).
> 
> If the idea is to keep users from using the file, why do we need to
> worry about nesting of comments?  Just throw a chunk of uncommented
> English text at the top of the file and let it fail.

Greps and such won't report that a reference is in a doomed file,
and the commenting protects from browsers like S**rc* N*v*g*t*r.

I also don't put complete faith in CVS, because unless one tags
before removal of a set of related changes, you'll never find
them all again, and historically people have not tagged before
evaporating things.  Releases get archived in many places,
including durable media.

(Lest you think this is going overboard, consider that Google
just went to a bunch of trouble to recover old Usenet postings,
and that much GNU development history is trapped in Cygnus's old
CVS repository that is contaminated with lots of proprietary stuff
and can never be opened to the public.)

Stan

Re: Remaining host configuration fragments

[Paul Koning]

Excerpt of message (sent 17 January 2002) by Stan Shebs:
> DJ Delorie wrote:
> > 
> > > would be simpler (no need to worry about nesting of comments).
> > 
> > If the idea is to keep users from using the file, why do we need to
> > worry about nesting of comments?  Just throw a chunk of uncommented
> > English text at the top of the file and let it fail.
> 
> Greps and such won't report that a reference is in a doomed file,
> and the commenting protects from browsers like S**rc* N*v*g*t*r.

I wonder if this is going further than is really necessary.

A clean solution for questionable targets is to disallow them in
configure, possibly with a --enable-obsolete-targets override as has
been suggested.  One advantage is that this is a localized change.

Given the above, I don't really see the point in causing compile
errors when compiling the target components themselves.  But if you
want that, a very simple way to force errors is just a
     #error "this file is obsolete"
Right?

	paul

Re: Remaining host configuration fragments

[Richard Kenner]

    I asked in three places whether anyone was using GCC to compile code
    for the PDP-11: the PDP Unix Preservation Society mailing list (where
    the 2.11BSD maintainer lurks), the classiccmp mailing list, and the
    alt.sys.pdp11 newsgroup.  In all cases, there were no voices raised in
    defense of the PDP-11 back end in GCC.

Which suggests that the people using it are not in those forums.

I'd be very hesitant to remove a back-end that was recently added to GCC
no matter how little use we think it's getting.

Re: Remaining host configuration fragments

[Joe Buck]

Kenner writes:

> I'd be very hesitant to remove a back-end that was recently added to GCC
> no matter how little use we think it's getting.

In this case [pdp11] it seems that several maintainers are willing to
spend a few cycles hacking on it, so let's just leave it.

On the other hand, the elxsi backend is still there.  Mike Stump,
didn't you let us know a few years ago that the last ELXSI machine
had been turned off some time ago?

Re: Remaining host configuration fragments

[Lars Brinkhoff]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
>     I asked in three places whether anyone was using GCC to compile code
>     for the PDP-11: the PDP Unix Preservation Society mailing list (where
>     the 2.11BSD maintainer lurks), the classiccmp mailing list, and the
>     alt.sys.pdp11 newsgroup.  In all cases, there were no voices raised in
>     defense of the PDP-11 back end in GCC.
> Which suggests that the people using it are not in those forums.

Right, I was just trying to collect some anecdotal evidence.

Paul Koning <pkoning@equallogic.com> writes:
> Perhaps that's because the backend in its current state doesn't
> actually work.  I've been tinkering with it (inspired by the new pdp11
> GAS support).  It's getting closer.

Great!  Here's some sort of user feedback, dunno if it's useful to you:

  Harti Brandt <hbb@fokus.gmd.de> writes:
  > Last time I tried it, it was incredibly broken (around
  > gcc-2.6.X). One of the big problems was, that gcc had hard coded
  > optimisations which assume, that the address space is large. If you,
  > for example, divide an integer by 10, it will generate you a
  > screenful of assembler code, which is bad in almost any case on a
  > PDP11. Dividing unsigned longs was even worse and you couldn't tell
  > gcc that it should call a library function for this. I don't know,
  > whether this has changed in newer gcc's.
  >               brandt@fokus.fhg.de

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