Discussion:
GCC 4.3 target deprecation proposals
Joseph S. Myers
2008-01-21 19:06:52 UTC
Permalink
No targets have been deprecated since 4.0, so it seems time to
consider deprecating unused targets again. The usual procedure would
apply: targets would require --enable-obsolete to build them in 4.3,
then the code (and docs, testsuite support etc.) would be removed some
time after 4.3.0 is released if no-one comes forward to resurrect the
target support. If someone does come forward, patches to resurrect
the support could be accepted even in the 4.3 branch if it is clear
they would not affect other targets.

First, I propose removing c4x support, which has been in the obsolete
state since 4.0 without being removed. This does not mean removal of
any support or abstractions present elsewhere in the compiler to
support non-8-bit bytes; just c4x-specific code.

I have applied the following methodology to choose targets to propose
obsoleting:

* Any target with test results posted to gcc-testresults within the
past year, or mentioned on gcc-patches within the last year as having
been used to test a patch (not just building cc1; testing that the
resulting compiler works), is considered alive and not proposed for
deprecation. OS version numbers etc. that don't affect the GCC
configuration are not considered significant; other slight variants
with the same architecture and OS may also be accepted as alive
without needing test results for every variant target triplet.
(Though some such triplets might better be handled with configure
options such as --with-arch and --with-abi.)

The principle here is that any target (especially any target
architecture) involves maintenance cost for many global patches; as
such, maintainer responsibilities include testing and sending test
results from time to time to show that the target still works, and
fixing problems arising from changes to core code. If you cannot
maintain a target on an ongoing basis, posting the patch to
gcc-patches and assigning to the FSF, but explicitly without proposing
addition to GCC trunk, may serve the purpose of making the patch
available to anyone wishing to use it without imposing the cost on GCC
maintenance.

* If any target from an architecture is alive, generic targets such as
-elf -coff -aout -eabi -pe for that architecture are also considered
alive. If an OS is alive for some architectures it may also be
considered alive for others unless there is reason to believe that the
combination is no longer alive despite both OS and architecture being
alive.

The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax. Of these targets, score appears to be actively
maintained; I suggest that the SC appoint Chen Liqin
<***@sunnorth.com.cn> as the official maintainer of this port, if
not already done, and I suggest to Chen Liqin that he add himself to
the MAINTAINERS file and start posting test results for this port to
gcc-testresults using the contrib/test_summary script. I found
mention of one patch having been tested on vax-netbsdelf; I encourage
the maintainers to try to run the testsuite and send testresults for
trunk at least once a year.

Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent
testing or development. Joern Rennecke was intending to improve ARC
support but is listed as "Waiting for paperwork" in MAINTAINERS; is
there any news on that assignment? I propose obsoleting crx, iq2000,
mt, pdp11 and stormy16 unless someone steps forwards and indicates
that they have recently tested trunk for one of those targets and it
is working, or that they intend to test trunk and ensure it is in good
shape for their target before 4.4 is released. Intentions would not
in my view suffice if the same intentions have been expressed for the
same target in response to a previous deprecation proposal, although
the final approval of target deprecations is up to a global write
maintainer or the SC.

I will consider deprecations of individual targets for architectures
separately depending on the reaction to this deprecation proposal.
People may also make their own proposals for deprecations, including
relating to targets which have had results posted in the past year,
and including deprecations of particular subconfigurations (e.g. using
a particular target without the GNU assembler, or with a particular
debug format). I note the lack of anyone posting test results for
uClinux, OpenBSD or RTEMS, and suggest that users of those operating
systems should try to post test results for at least some target
architectures.

The list of targets for which I found test results is attached.
--
Joseph S. Myers
***@codesourcery.com
John David Anglin
2008-01-21 20:05:04 UTC
Permalink
Post by Joseph S. Myers
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.
Regarding vax, I don't have the time to maintain it. HPPA has taken
all my free time in the past year. I probably should remove my name
as a vax maintainer.

There is still a small amount of vax related activity but I don't
expect the GCC port to be actively maintained. The community is too
small. So, I think it is reasonable to consider it for removal.
I recall in the last go around that some people thought it should
be maintained as an example.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Paul Koning
2008-01-21 22:03:21 UTC
Permalink
Post by Joseph S. Myers
The following target architectures have seen no test results
posted in the past year: arc, c4x (as listed above), crx, iq2000,
mt, pdp11, score, stormy16, vax.
Thanks David.

I fixed my gcc list subscriptions which had become lost at some point
due to malfunctions of internal mailers.

Regarding the pdp11 target, I would like to keep it alive and will do
testcase work as necessary for that purpose. Admittedly, the
community is bound to be even smaller than the one for vax.

If people feel that it doesn't really make sense to keep pdp11 alive,
please speak up. I can certainly be talked out of it, but I feel it
isn't right for me to let it lapse simply for lack of attention.

paul
Joseph S. Myers
2008-01-21 22:13:13 UTC
Permalink
Post by John David Anglin
There is still a small amount of vax related activity but I don't
expect the GCC port to be actively maintained. The community is too
small. So, I think it is reasonable to consider it for removal.
I recall in the last go around that some people thought it should
be maintained as an example.
I didn't propose it for removal because of a single patch
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00511.html> reported to have
been tested on vax-netbsdelf. If the maintainers wish to propose
deprecation and no-one else wishes to come forward to maintain it, we can
certainly include it in the deprecations; otherwise, all vax targets other
than vax-netbsdelf and maybe vax-openbsd are likely to appear in the list
of individual targets to deprecate for lack of even a single patch tested
there.
--
Joseph S. Myers
***@codesourcery.com
Ben Elliston
2008-01-21 23:01:55 UTC
Permalink
Post by Joseph S. Myers
I didn't propose it for removal because of a single patch
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00511.html> reported to have
been tested on vax-netbsdelf. If the maintainers wish to propose
deprecation and no-one else wishes to come forward to maintain it, we can
certainly include it in the deprecations; otherwise, all vax targets other
than vax-netbsdelf and maybe vax-openbsd are likely to appear in the list
of individual targets to deprecate for lack of even a single patch tested
there.
My understanding is that NetBSD port to the vax is very much alive and
maintained. Thus, I expect that those users (eg Matt Thomas) would like
to see the GCC port retained.

Ben
Joe Buck
2008-01-22 02:03:40 UTC
Permalink
Post by Ben Elliston
Post by Joseph S. Myers
I didn't propose it for removal because of a single patch
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00511.html> reported to have
been tested on vax-netbsdelf. If the maintainers wish to propose
deprecation and no-one else wishes to come forward to maintain it, we can
certainly include it in the deprecations; otherwise, all vax targets other
than vax-netbsdelf and maybe vax-openbsd are likely to appear in the list
of individual targets to deprecate for lack of even a single patch tested
there.
My understanding is that NetBSD port to the vax is very much alive and
maintained. Thus, I expect that those users (eg Matt Thomas) would like
to see the GCC port retained.
How can we encourage the NetBSD folks to participate more directly,
including helping to test the trunk? I haven't been following NetBSD
carefully, but I get the impression that at least some of the BSDs
work with older gcc branches, staying away from the bleeding edge,
and this could put some of their ports at risk if we have no one to
test the compiler.
John David Anglin
2008-01-22 23:52:42 UTC
Permalink
Post by Joe Buck
Post by Ben Elliston
My understanding is that NetBSD port to the vax is very much alive and
maintained. Thus, I expect that those users (eg Matt Thomas) would like
to see the GCC port retained.
How can we encourage the NetBSD folks to participate more directly,
including helping to test the trunk? I haven't been following NetBSD
carefully, but I get the impression that at least some of the BSDs
work with older gcc branches, staying away from the bleeding edge,
and this could put some of their ports at risk if we have no one to
test the compiler.
Here are a few of my thoughts and suggestions on this issue:

1) From personal experience, I know that it is a major commitment for
someone to become a port maintainer. It takes a lot of time to keep
a port going at the bleeding edge. In addition, skill is needed to
argue the merit of changes to the compiler outside the area of
responsibility of the port maintainer. The maintainer may have to
maintain a farm of machines with different operating systems. In
my case, I have been fortunate that the National Research Council
of Canada has provided space and resources for machines. HP has
donated a number of machines.

For folks primarily interested in an OS port, the GCC requirement to
build and test the port on a regular basis is just another hurdle
in getting their port working. Thus, I can see why many hesitate to
become port maintainers.

2) For ports that support full blown operating systems, it would seem
that simulators provide a mechanism to develop and test these ports.
Current PCs certainly have the power to do this testing. So, it might
be helpful if a set of GCC test simulators were setup and available
for download.

3) I think the GCC release cycle may be too fast for many distributions.
We also may be closing branches too early.

I believe TheWrittenWord is using 3.4 for its HP-UX and AIX distributions.
Apple Panther used 3.3, Tiger 4.0.1. Don't know about Leopard. Debian
Lenny is using 4.1 and it's not yet stable. The main point is
distros pick a GCC version and stay with it for the life of each
distribution. It's quite possible that the GCC project will stop
maintainence of the version being used before a distribution is
released.

As a result, I think the distros have to perform their own GCC
maintenance. Nobody is going to pay any attention to a bug reported
against a GCC version that is no longer maintained unless it is still
present in the head.

4) The GCC project may be too strict about applying fixes to previous
releases. The home page suggests that only regression fixes can
be applied to previous releases. In practice, the project isn't
that strict and allows fixes for important bugs to be applied to
previous releases if they aren't risky.

I can point to at least one situation where blindly freezing a
product has led to a situation where the application is non functional
for many users and the company is ignoring requests for a fix.
As a result, the company is experiencing a public relations nightmare.

The main reason I mention this is that it may take one or two
releases before the cause of a bug surfaces when a port has limited
support.

I don't think GCC has major product problems but it might be interesting
to do a statistical study of bugs reported against released versions.

In sumary, there is a tricky balance in all this. The stage1 renewal
is clearly essential for the health of GCC. On the otherhand, we can't
lose sight of the fact that GCC is a tool that must be reliable and
standards complient. Sometimes stage1 requires a lot of work on the
part of port maintainers. Port maintainers often have to do the initial
leg work to debug and classify bugs.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Matt Thomas
2008-01-22 06:55:26 UTC
Permalink
Post by Ben Elliston
Post by Joseph S. Myers
I didn't propose it for removal because of a single patch
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00511.html> reported to have
been tested on vax-netbsdelf. If the maintainers wish to propose
deprecation and no-one else wishes to come forward to maintain it, we can
certainly include it in the deprecations; otherwise, all vax
targets other
than vax-netbsdelf and maybe vax-openbsd are likely to appear in the list
of individual targets to deprecate for lack of even a single patch tested
there.
My understanding is that NetBSD port to the vax is very much alive and
maintained. Thus, I expect that those users (eg Matt Thomas) would like
to see the GCC port retained.
We would. I have gcc working with gcc4.3 but gcc's use mpfr/gmp has
made
native test impossible since neither work on vax/elf. I don't have time
to make them work.
Joseph S. Myers
2008-01-22 13:18:08 UTC
Permalink
We would. I have gcc working with gcc4.3 but gcc's use mpfr/gmp has made
native test impossible since neither work on vax/elf. I don't have time
to make them work.
They don't work even with --host=none-unknown-netbsdelf to use the generic
C code instead of the VAX assembly?
--
Joseph S. Myers
***@codesourcery.com
Jan-Benedict Glaw
2008-01-23 11:09:10 UTC
Permalink
Post by Matt Thomas
Post by Ben Elliston
My understanding is that NetBSD port to the vax is very much alive and
maintained. Thus, I expect that those users (eg Matt Thomas) would like
to see the GCC port retained.
We would. I have gcc working with gcc4.3 but gcc's use mpfr/gmp has
made
native test impossible since neither work on vax/elf. I don't have time
to make them work.
I do have a crude patch to ELFify the assembly parts. However,
upstream told me that it wouldn't be accepted since it would break
older setups and that M4 magic should be used to sort out the %
story...

I was able to canadian-build a target=host vax-linux-uclibc compiler with
that (plus linux-specific patches) using a i686-linux-gnu build
machine.

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Wenn ich wach bin, trÀume ich.
the second :
Jan-Benedict Glaw
2008-01-23 11:20:17 UTC
Permalink
Post by Jan-Benedict Glaw
I do have a crude patch to ELFify the assembly parts. However,
This was ment to be attached...

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second : Langsam möchte ich mal wieder weitertrÀumen können.
-- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
NightStrike
2008-01-22 09:06:17 UTC
Permalink
Post by John David Anglin
Post by Joseph S. Myers
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.
Regarding vax, I don't have the time to maintain it. HPPA has taken
all my free time in the past year. I probably should remove my name
as a vax maintainer.
There is still a small amount of vax related activity but I don't
expect the GCC port to be actively maintained. The community is too
small. So, I think it is reasonable to consider it for removal.
I recall in the last go around that some people thought it should
be maintained as an example.
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Paolo Bonzini
2008-01-22 09:49:19 UTC
Permalink
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.

Paolo
Joseph S. Myers
2008-01-22 13:22:51 UTC
Permalink
Post by Paolo Bonzini
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.
Indeed, testing is needed to provide evidence that a target works, but in
practice some developer work is needed to fix problems that show up in
testing (for example, target-specific problems exposed by the df work) and
without such work target architectures are unlikely to remain working well
between major releases. However, I only looked to see if there was any
development on a platform if I saw there had been no testing at all
(posted to gcc-testresults) since the start of 2007.
--
Joseph S. Myers
***@codesourcery.com
Jan-Benedict Glaw
2008-01-23 11:16:00 UTC
Permalink
Post by Joseph S. Myers
Post by Paolo Bonzini
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.
Indeed, testing is needed to provide evidence that a target works, but in
practice some developer work is needed to fix problems that show up in
testing (for example, target-specific problems exposed by the df work) and
without such work target architectures are unlikely to remain working well
between major releases. However, I only looked to see if there was any
development on a platform if I saw there had been no testing at all
(posted to gcc-testresults) since the start of 2007.
When I had move time available (and I hope that this'll be the case
again), I ran a vax-linux-uclibc build every 4h to catch breaking
patches early.

For all others who are thinking about stepping up as a maintainer:
You'll loose eons of time if you don't do something similar,
especially for those targets that have virtually no users. It's quite
time consuming to check the last two months of commits for candidates
that broke your build.

Build often, build automatically, and keep the commit emails. For GCC
as well as the binutils and your libc.

I'm quite interested in the VAX target, specifically the Linux bits
I'm having around, but I'm unsure about my current time constraints.
Right now, I wouldn't do promises on that, but I'd be willing to look
into upcoming problems.

Some SIMH instance with a CURRENT NetBSD would probably be helpful and
if somebody helps me to get a NetBSD up'n'running with SIMH, I'd offer
to put my auto-building scripts in there. NetBSD is at least a
somewhat complete OS, while Linux is still flanky and needs more work,
especially with GNU libc and TLS...

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Gib Dein Bestes. Dann ÃŒbertriff Dich selbst!
the second :
Joe Buck
2008-01-22 18:31:35 UTC
Permalink
Post by Paolo Bonzini
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.
Yes. The problem is that often users of ancient hardware will also
be users of very old versions of the software; if they don't help test
the latest code (the gcc trunk), then there's no way to tell whether
the latest code actually works. Code that is not tested is almost
always broken code.

Remember that Joseph's message that started this thread said that one
criterion would be that no test results have been reported to
gcc-testresults for a year. If you start contributing test results
for a port, then it might (no promises) be removed from any deprecation
lists (unless the report says you can't even build the compiler and
no one can be found to help fix it).

So if you're a vax user, you can help keep the vax port alive by helping
to test it, reporting bugs, and testing proposed fixes. That's no
guarantee, by the way, as volunteers are still needed to implement
the fixes. Your company might want to consider contributing either
staff time or money to pay a consultant to help with maintaining the
vax port if it's important to you.
Jan-Benedict Glaw
2008-01-23 11:18:31 UTC
Permalink
Post by Joe Buck
Post by Paolo Bonzini
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.
So if you're a vax user, you can help keep the vax port alive by helping
to test it, reporting bugs, and testing proposed fixes. That's no
guarantee, by the way, as volunteers are still needed to implement
the fixes. Your company might want to consider contributing either
staff time or money to pay a consultant to help with maintaining the
vax port if it's important to you.
Okay... So I'll try to get a NetBSD installation in SIMH running
these days. Matt et al, if you have some beforehand tips for me (like
choosing the "best" HDD types etc.) it would be nice if you would drop
me an email.

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Fortschritt bedeutet, einen Schritt so zu machen,
the second : daß man den nÀchsten auch noch machen kann.
Jan-Benedict Glaw
2008-01-23 11:57:00 UTC
Permalink
Post by Jan-Benedict Glaw
Post by Joe Buck
So if you're a vax user, you can help keep the vax port alive by helping
to test it, reporting bugs, and testing proposed fixes. That's no
guarantee, by the way, as volunteers are still needed to implement
the fixes. Your company might want to consider contributing either
staff time or money to pay a consultant to help with maintaining the
vax port if it's important to you.
Okay... So I'll try to get a NetBSD installation in SIMH running
these days. Matt et al, if you have some beforehand tips for me (like
choosing the "best" HDD types etc.) it would be nice if you would drop
me an email.
Most specific questions:

- What is the largest HDD SIMH supports? There seems to be RA92
support, but that's only 1.5GB. With today's software, I guess
the build requirements (checked-out trees of the software incl.
SCM metadata, ...) are way above that :)

What's the best way to get a "real" amount of storage into NetBSD
on SIMH? NFS-mounting something from outside?

- The NetBSD SIMH HOWTO
(http://www.netbsd.org/ports/vax/emulator-howto.html) refers to
load the ka655.bin eprom image, but upstream SIMH "only" contains
the hacked version (ka655x.bin), which supports more RAM. Is it
okay to assume NetBSD will accept this hacked ROM and give me as
much RAM inside the instance as possible with it?

Thanks, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Arroganz verkÌrzt fruchtlose GesprÀche.
the second : -- Jan-Benedict Glaw
Jan-Benedict Glaw
2008-01-25 01:53:34 UTC
Permalink
Post by Jan-Benedict Glaw
- What is the largest HDD SIMH supports? There seems to be RA92
support, but that's only 1.5GB. With today's software, I guess
the build requirements (checked-out trees of the software incl.
SCM metadata, ...) are way above that :)
What's the best way to get a "real" amount of storage into NetBSD
on SIMH? NFS-mounting something from outside?
SIMH allows arbitrarily sized disks. Don't use "set rq0 ra92", but
"set rq0 rauser=20000" to get about 20GB.
Post by Jan-Benedict Glaw
- The NetBSD SIMH HOWTO
(http://www.netbsd.org/ports/vax/emulator-howto.html) refers to
load the ka655.bin eprom image, but upstream SIMH "only" contains
the hacked version (ka655x.bin), which supports more RAM. Is it
okay to assume NetBSD will accept this hacked ROM and give me as
much RAM inside the instance as possible with it?
Seems this will work with NetBSD. Maximum amount of RAM can be get
with "set cpu 512m".

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Fortschritt bedeutet, einen Schritt so zu machen,
the second : daß man den nÀchsten auch noch machen kann.
John David Anglin
2008-01-22 18:12:59 UTC
Permalink
Post by Paolo Bonzini
Neither, actually. It's tester base that counts the most.
I had a discussion with Jan-Benedict Glaw last night about this. He
Post by Paolo Bonzini
The damn thing is that we need a working kernel + userland. Irrelevant
of the actual operating system. Maybe it would be better to start
looking at NetBSD in depth to get it up'n'running in a SIMH instance
and test GCC with it.
From the reports I have, the vax port still builds and the amount of
rot is limited at this time. Matt has a big patch to add PIC support.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Laurent GUERBY
2008-01-22 11:34:47 UTC
Permalink
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
What GCC version are you using and do you contribute build test results
to gcc-***@gcc.gnu.org ?

Laurent
Andrew Haley
2008-01-22 13:43:02 UTC
Permalink
Post by NightStrike
Post by John David Anglin
Post by Joseph S. Myers
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.
Regarding vax, I don't have the time to maintain it. HPPA has taken
all my free time in the past year. I probably should remove my name
as a vax maintainer.
There is still a small amount of vax related activity but I don't
expect the GCC port to be actively maintained. The community is too
small. So, I think it is reasonable to consider it for removal.
I recall in the last go around that some people thought it should
be maintained as an example.
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
While the idea of weighing the user base when deprecating a target seems
to make some emotional sense, it doesn't make any practical sense. The
compiler has to be maintained by someone or it will rot and cease to be
buildable, then it won't be of any use to users anyway. If there isn't an
active maintainer we can't continue to include a target, no matter how many
users it has.

Andrew.
Manuel López-Ibáñez
2008-01-22 14:06:08 UTC
Permalink
Post by Andrew Haley
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
While the idea of weighing the user base when deprecating a target seems
to make some emotional sense, it doesn't make any practical sense. The
compiler has to be maintained by someone or it will rot and cease to be
buildable, then it won't be of any use to users anyway. If there isn't an
active maintainer we can't continue to include a target, no matter how many
users it has.
I agree that weighing the user base doesn't make any practical sense.
But I can't understand the reason for removing something that works
fine because it may rot in the future. I understand that if you don't
get test results then you may assume there are no users. But if you
get test results and they are fairly clean?

Another different matter would be if there were a lot of test failures
and open bug reports. Then it will be fair to send all test-results
reporters and bug subscribers a message saying:

"If no one steps up to maintain this, the target will be removed in
the next release."

I would propose to send the message in stage1 (and probably at stage2
and stage3) and decide in stage3.

It will also be fair to suspend bugs for targets that have no active
maintainer with an appropriate message.

Cheers,

Manuel.
Andrew Haley
2008-01-22 14:19:13 UTC
Permalink
Post by Manuel López-Ibáñez
Post by Andrew Haley
Post by NightStrike
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
While the idea of weighing the user base when deprecating a target seems
to make some emotional sense, it doesn't make any practical sense. The
compiler has to be maintained by someone or it will rot and cease to be
buildable, then it won't be of any use to users anyway. If there isn't an
active maintainer we can't continue to include a target, no matter how many
users it has.
I agree that weighing the user base doesn't make any practical sense.
But I can't understand the reason for removing something that works
fine because it may rot in the future. I understand that if you don't
get test results then you may assume there are no users. But if you
get test results and they are fairly clean?
The interface between gcc and the back-ends changes fairly frequently,
so it's necessary for a target to be maintained or it will cease to work.
Post by Manuel López-Ibáñez
Another different matter would be if there were a lot of test failures
and open bug reports. Then it will be fair to send all test-results
"If no one steps up to maintain this, the target will be removed in
the next release."
That's what target deprecation is: we always deprecate in one release cycle
and delete in a subsequent cycle.

Andrew.
Weddington, Eric
2008-01-23 15:32:24 UTC
Permalink
-----Original Message-----
Sent: Tuesday, January 22, 2008 7:19 AM
To: Manuel López-Ibáñez
Subject: Re: GCC 4.3 target deprecation proposals
Post by Manuel López-Ibáñez
I agree that weighing the user base doesn't make any
practical sense.
Post by Manuel López-Ibáñez
But I can't understand the reason for removing something that works
fine because it may rot in the future. I understand that if
you don't
Post by Manuel López-Ibáñez
get test results then you may assume there are no users. But if you
get test results and they are fairly clean?
The interface between gcc and the back-ends changes fairly frequently,
so it's necessary for a target to be maintained or it will
cease to work.
Post by Manuel López-Ibáñez
Another different matter would be if there were a lot of
test failures
Post by Manuel López-Ibáñez
and open bug reports. Then it will be fair to send all test-results
"If no one steps up to maintain this, the target will be removed in
the next release."
That's what target deprecation is: we always deprecate in
one release cycle
and delete in a subsequent cycle.
I've been lurking on this list long enough to see the same questions, with the same answers, every time the subject of target deprecations comes up.

If it doesn't exist somewhere already, can the criteria that Joseph used be set as a recurring policy and documented somewhere? Can we have an FAQ set up somewhere for the inevitable questions/concerns that follow the release of a proposed target deprecation list?

Eric Weddington
Manuel López-Ibáñez
2008-01-23 16:34:44 UTC
Permalink
Post by Weddington, Eric
I've been lurking on this list long enough to see the same questions, with the same answers, every time the subject of target deprecations comes up.
If it doesn't exist somewhere already, can the criteria that Joseph used be set as a recurring policy and documented somewhere? Can we have an FAQ set up somewhere for the inevitable questions/concerns that follow the release of a proposed target deprecation list?
Anybody can edit the wiki: http://gcc.gnu.org/wiki/TargetDeprecationFAQ

;-)

Manuel.
Weddington, Eric
2008-01-23 20:23:42 UTC
Permalink
-----Original Message-----
Sent: Wednesday, January 23, 2008 9:35 AM
To: Weddington, Eric
Subject: Re: GCC 4.3 target deprecation proposals
Post by Weddington, Eric
I've been lurking on this list long enough to see the same
questions, with the same answers, every time the subject of
target deprecations comes up.
Post by Weddington, Eric
If it doesn't exist somewhere already, can the criteria
that Joseph used be set as a recurring policy and documented
somewhere? Can we have an FAQ set up somewhere for the
inevitable questions/concerns that follow the release of a
proposed target deprecation list?
http://gcc.gnu.org/wiki/TargetDeprecationFAQ
;-)
Ok, done. That link above.

I borrowed heavily from many people's responses in this thread. Hope that's ok. Feel free to edit/adjust as you see fit. :-)

Eric Weddington
Dave Korn
2008-01-22 17:47:29 UTC
Permalink
Post by Manuel López-Ibáñez
I agree that weighing the user base doesn't make any practical sense.
But I can't understand the reason for removing something that works
fine because it may rot in the future.
It's particularly with the lack of test results that that situation becomes
a problem. It's not about "removing something that works fine because it may
rot in the future" _as such_; it's about removing something that we don't even
know if it works or not, because in the absence of test results we will not
notice when that hypothetical future-when-it-doesn't-work becomes "now".
Post by Manuel López-Ibáñez
I understand that if you don't
get test results then you may assume there are no users.
No, I don't think we can assume that; I think we can only infer that, if we
see no testresults, there are no /developers/.
Post by Manuel López-Ibáñez
But if you get test results and they are fairly clean?
Well, we'll cross that bridge *if* we come to it, but, as Joseph points out,
there haven't been any test results in over a year.

cheers,
DaveK
--
Can't think of a witty .sigline today....
Joel Sherrill
2008-01-22 17:58:15 UTC
Permalink
Post by Joseph S. Myers
I note the lack of anyone posting test results for
uClinux, OpenBSD or RTEMS, and suggest that users of those operating
systems should try to post test results for at least some target
architectures.
Sorry. For RTEMS, this just reflects a lack of success in
getting the scripts to run with all the magic bits right
for an installed cross gcc with extra arguments required
to compile and link.

If someone familiar with the test suite scripts could
help us, we could move on from there to test the SVN
trunk on a few RTEMS targets on a regular basis.

I manually run the Ada ACATS test suite on at least
the SPARC and PowerPC fairly regularly but only
report failures by hand. For 4.2.2 the results were
near perfect.

--joel
Ben Elliston
2008-01-23 05:22:36 UTC
Permalink
Post by Manuel López-Ibáñez
I agree that weighing the user base doesn't make any practical sense.
But I can't understand the reason for removing something that works
fine because it may rot in the future.
Every port, working or not, imposes a certain amount of maintenance
overhead. It also adds inertia, because a small change that affects
every backend might discourage someone from making that change, even if
it's the right thing to do.

Ben
Eric Botcazou
2008-01-21 20:47:57 UTC
Permalink
Post by Joseph S. Myers
People may also make their own proposals for deprecations, including
relating to targets which have had results posted in the past year,
and including deprecations of particular subconfigurations (e.g. using
a particular target without the GNU assembler, or with a particular
debug format).
I propose to deprecate the *-*-solaris2.5 and *-*-solaris2.6 targets, the OS
were released more than a decade ago. The minimal supported version would
then be Solaris 7, the first version that can support DWARF-2 debug info.
--
Eric Botcazou
Joseph S. Myers
2008-01-21 22:21:18 UTC
Permalink
Post by Eric Botcazou
Post by Joseph S. Myers
People may also make their own proposals for deprecations, including
relating to targets which have had results posted in the past year,
and including deprecations of particular subconfigurations (e.g. using
a particular target without the GNU assembler, or with a particular
debug format).
I propose to deprecate the *-*-solaris2.5 and *-*-solaris2.6 targets, the OS
were released more than a decade ago. The minimal supported version would
then be Solaris 7, the first version that can support DWARF-2 debug info.
For reference, the last test results posted for either of these seem to be
yours last July, so given your deprecation proposal we can take it there
is no evidence of current GCC users for these platforms at present. If
these targets are removed, I believe we can remove
--enable-threads={posix95,solaris} support along with them.
--
Joseph S. Myers
***@codesourcery.com
Arnaud Charlet
2008-01-22 08:08:40 UTC
Permalink
Post by Joseph S. Myers
For reference, the last test results posted for either of these seem to be
yours last July, so given your deprecation proposal we can take it there
is no evidence of current GCC users for these platforms at present. If
these targets are removed, I believe we can remove
--enable-threads={posix95,solaris} support along with them.
solaris threads still exist in more recent Solaris versions and can still be
useful, so this is really orthogonal to the solaris 2.5/6 deprecation.

We are using --enable-threads=solaris extensively at AdaCore, so obviousely
would like to see this option kept.

Arno
Nathan Sidwell
2008-01-22 07:56:21 UTC
Permalink
Post by Joseph S. Myers
Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent
testing or development. Joern Rennecke was intending to improve ARC
I have no objection to mt.

nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery
l***@sunnorth.com.cn
2008-01-23 01:52:34 UTC
Permalink
Post by Joseph S. Myers
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax. Of these targets, score appears to be actively
maintained; I suggest that the SC appoint Chen Liqin
not already done, and I suggest to Chen Liqin that he add himself to
the MAINTAINERS file and start posting test results for this port to
gcc-testresults using the contrib/test_summary script. I found
mention of one patch having been tested on vax-netbsdelf; I encourage
the maintainers to try to run the testsuite and send testresults for
trunk at least once a year.
I had been maintained the gcc score backend for more than one year, but
still
do not know to became the offical maintainer of this port.

BTW, I will provide the score gcc-testresults soon (C/C++).

Best Regards
Liqin
Joseph S. Myers
2008-01-23 14:39:37 UTC
Permalink
Following my proposal for target architecture deprecations in 4.3
<http://gcc.gnu.org/ml/gcc/2008-01/msg00335.html>, I now propose the
following list of individual targets to deprecate, based on the same
methodology previously described. The patch to remove c4x and
deprecate the previously discussed target architectures crx, iq2000,
mt, stormy16 will be submitted shortly; the patch for the remaining
deprecations (only touching config.gcc and the release notes) will be
submitted later after any discussion.

* c4x to be removed before 4.3, as previously mentioned.

* Stray ns32k stanzas left in config.gcc after config/ns32k was
removed to be removed. Likewise, stray h8300-*-rtemscoff* and
sh-*-rtemscoff* stanzas since *-*-rtemscoff* is marked as
unsupported earlier in the file.

The following to be deprecated in 4.3 and removed in 4.4 (some time
after 4.3.0 is released) in the absence of activity to revive them
(which means at least testing from time to time and reporting they
work or sending and chasing up patches to fix them):

* crx, iq2000, mt, stormy16 (all configurations), as previously
mentioned.

* strongarm*-*-*, ep9312*-*-*, xscale*-*-* (the alternative CPU names
in target triplets for certain ARM targets). There has been no
activity recently using these aliases, and such aliases acted on by
config.gcc are more problematic than those substituted by config.sub
(for example, testcases need to include them in their target triplet
lists). If someone wishes to revive these targets, I think they
should move to them being aliases processed by config.sub, with
config.gcc checking the noncanonical name and selecting --with-cpu
etc. options on that basis.

* parisc*-*-*, alias for hppa*-*-*. Also apparently an unused alias
handled by config.gcc that should move to config.sub if desired.

* m680[012]0-*-* aliases for m68k-*-*. I see no activity using these
aliases and they appear fully equivalent to --with-cpu options that
already exist; anyone wishing the continue to use them can move them
to config.sub and make config.gcc treat them as --with-cpu based on
the noncanonical name.

* *-*-beos*

* *-*-kaos*

* *-*-linux*aout*

* *-*-linux*libc1*

* *-*-solaris2.[0-6], *-*-solaris2.[0-6].*, as proposed by Eric
Botcazou.

* *-*-sysv*

* *-*-windiss*

* alpha*-*-unicosmk*

* hppa1.1-*-pro*

* hppa1.1-*-osf*

* hppa1.1-*-bsd*

* i[34567]86-sequent-ptx4*

* i[34567]86-*-nto-qnx*

* i[34567]86-*-sco3.2v5*

* i[34567]86-*-uwin*

* powerpc-*-chorusos*

* vax-*-bsd*

* vax-*-sysv*

* vax-*-ultrix*

There are many more targets I haven't listed, with a lack of test
results and varying amounts of evidence of use or testing of patches.
OSes needing more coverage in posted results include GNU HURD,
uClinux, OpenBSD, NetBSD (most platforms), *-*-kfreebsd*-gnu,
*-*-knetbsd*-gnu (BSD kernel with GNU libc), RTEMS, VxWorks, VMS,
DJGPP, Interix, WinCE, NetWare, LynxOS and s390x-ibm-tpf*; some people
may wish to propose deprecations of some of these if they feel they
are no longer being used with GCC. There is good coverage for
bare-metal ELF targets, but none for bare-metal a.out and COFF targets
(perhaps we should consider deprecating all of those, on the
presumption that bare-metal use has moved to ELF and objcopy is likely
to be used in any case to produce a raw binary image; -pe targets are
not being tested either); and good coverage for GNU/Linux on many
platforms. Darwin and Solaris are being tested on relevant platforms;
HP-UX is only being tested on hppa, not IA64.

One question of interest is whether some targets supporting both GNU
and non-GNU assembler can have use of non-GNU assembler deprecated.
If this could be done for alpha*-dec-osf[45]*, we could remove
mips-tdump and mips-tfile.
--
Joseph S. Myers
***@codesourcery.com
Andreas Schwab
2008-01-23 16:03:33 UTC
Permalink
Post by Joseph S. Myers
* m680[012]0-*-* aliases for m68k-*-*. I see no activity using these
aliases and they appear fully equivalent to --with-cpu options that
already exist; anyone wishing the continue to use them can move them
to config.sub and make config.gcc treat them as --with-cpu based on
the noncanonical name.
I'm not sure what you mean with that. config.sub already recognizes
m680[012]0 as cpu type.

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Joseph S. Myers
2008-01-23 16:45:21 UTC
Permalink
Post by Andreas Schwab
Post by Joseph S. Myers
* m680[012]0-*-* aliases for m68k-*-*. I see no activity using these
aliases and they appear fully equivalent to --with-cpu options that
already exist; anyone wishing the continue to use them can move them
to config.sub and make config.gcc treat them as --with-cpu based on
the noncanonical name.
I'm not sure what you mean with that. config.sub already recognizes
m680[012]0 as cpu type.
If config.sub already converts them to m68k, so that m680[012]0 never
appears in a canonical target name, then the code in config.gcc looking
for m680[012]0 in canonical target names is already dead. The proposed
alias deprecations relate only to aliases appearing in canonical names,
not those that config.sub handles (such as converting pentium-linux to
i586-pc-linux-gnu).

If config.sub handles a target alias, config.gcc doesn't need to include
it in the case statements, and testcases do not need to mention that
alias. Thus testcases don't need to know about the possibility of
configuring for target pentium-linux. If config.sub does not handle a
target alias, testcases do need to know about it - and testcases checking
for m68k-*-* fail to check for the other variant target aliases.

There are no test results recently posted for the m680[012]0 target
aliases.
--
Joseph S. Myers
***@codesourcery.com
Andreas Schwab
2008-01-23 17:14:44 UTC
Permalink
Post by Joseph S. Myers
If config.sub already converts them to m68k, so that m680[012]0 never
appears in a canonical target name, then the code in config.gcc looking
for m680[012]0 in canonical target names is already dead. The proposed
alias deprecations relate only to aliases appearing in canonical names,
not those that config.sub handles (such as converting pentium-linux to
i586-pc-linux-gnu).
Thanks, I see your point now. AFAICS, none of the systems that
config.guess would return something matching m680[012]0-*-* are still
supported by gcc.

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
DJ Delorie
2008-01-23 17:02:30 UTC
Permalink
Post by Joseph S. Myers
DJGPP,
Please don't deprecate this. It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult. I don't think
we've *ever* run the testsuite for it.
Post by Joseph S. Myers
s390x-ibm-tpf*
Similar. TPF is cross, and there's no simulators, so no test results,
yet still active.
Post by Joseph S. Myers
-pe targets are not being tested either);
That would be cygwin, for i686 ;-)
Joseph S. Myers
2008-01-23 17:28:25 UTC
Permalink
Post by DJ Delorie
Post by Joseph S. Myers
DJGPP,
Please don't deprecate this. It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult. I don't think
we've *ever* run the testsuite for it.
Post by Joseph S. Myers
s390x-ibm-tpf*
Similar. TPF is cross, and there's no simulators, so no test results,
yet still active.
In that case these targets are something like SymbianOS (where the
compiler can be used through a Symbian SDK, but the *-*-symbianelf*
compiler can't be tested directly). But this was a list of targets I
suspect are used and am not proposing to deprecate but that lack test
coverage.

Cross targets can be tested on hardware without simulators (with
appropriate board files), even if some have particular difficulties in
testing. Some of the OSes listed have had patches submitted in the past
year that have been tested on them (using cross compilers and suitable
board files for testing on hardware). Others such as OpenBSD I expect are
largely used in native configurations.
Post by DJ Delorie
Post by Joseph S. Myers
-pe targets are not being tested either);
That would be cygwin, for i686 ;-)
That's being tested. WinCE was on the list of those OSes lacking test
coverage. I meant generic targets mcore-*-pe* and arm-*-pe* (since I see
[34567]86-*-pe is really an alias for Cygwin).
--
Joseph S. Myers
***@codesourcery.com
Ben Elliston
2008-01-24 00:18:39 UTC
Permalink
Post by DJ Delorie
Post by Joseph S. Myers
DJGPP,
Please don't deprecate this. It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult. I don't think
we've *ever* run the testsuite for it.
You can't cross-test, with DejaGnu running elsewhere?

Ben
DJ Delorie
2008-01-24 00:28:23 UTC
Permalink
Post by Ben Elliston
You can't cross-test, with DejaGnu running elsewhere?
I've tried. The problem is communication between the DOS system (or
emulator) and the host system. DOS isn't kind to networking,
semaphores, or anything else that hints at multiprocessing.
Ben Elliston
2008-01-24 00:34:56 UTC
Permalink
Post by DJ Delorie
I've tried. The problem is communication between the DOS system (or
emulator) and the host system. DOS isn't kind to networking,
semaphores, or anything else that hints at multiprocessing.
If you're trying to at least test code generation, etc., you could treat
the DOS system like a basic target board and cross-compile tests and
transfer them over a serial line to execute them. That's the way it was
done in the bad old days.

However, it's just occurred to me that you are probably wanting to test
djgpp as a native compiler. Yeah?

Ben
DJ Delorie
2008-01-24 00:41:34 UTC
Permalink
Post by Ben Elliston
If you're trying to at least test code generation, etc., you could
treat the DOS system like a basic target board and cross-compile
tests and transfer them over a serial line to execute them. That's
the way it was done in the bad old days.
Yeah, I remember those.
Post by Ben Elliston
However, it's just occurred to me that you are probably wanting to test
djgpp as a native compiler. Yeah?
That too.
Joe Buck
2008-01-24 00:44:34 UTC
Permalink
Post by Ben Elliston
Post by DJ Delorie
I've tried. The problem is communication between the DOS system (or
emulator) and the host system. DOS isn't kind to networking,
semaphores, or anything else that hints at multiprocessing.
If you're trying to at least test code generation, etc., you could treat
the DOS system like a basic target board and cross-compile tests and
transfer them over a serial line to execute them. That's the way it was
done in the bad old days.
However, it's just occurred to me that you are probably wanting to test
djgpp as a native compiler. Yeah?
What if you had a set of scripts that would fire up the DJGPP compiler
inside a DOS emulator on a Unix/Linux/whatever box and execute that? Then
if those scripts were named "gcc", "g++" etc. it would seem that you could
test native compilation that way. I haven't tried to hack dejagnu in
about a decade so I'm probably missing something, but it should be
feasible.
DJ Delorie
2008-01-24 00:53:08 UTC
Permalink
IIRC, the problem was in syncronizing *anything* between the Linux
host and the DOS emulator. It's like trying to use NFS to syncronize
two Xen instances, except with a flakey NFS and programs that don't
know about concurrency.

With Cygwin and DJGPP you have the problem of long command lines being
incompatibly passed between the two.
Kai Henningsen
2008-01-29 20:58:06 UTC
Permalink
Post by DJ Delorie
Post by Ben Elliston
You can't cross-test, with DejaGnu running elsewhere?
I've tried. The problem is communication between the DOS system (or
emulator) and the host system. DOS isn't kind to networking,
semaphores, or anything else that hints at multiprocessing.
Under Linux with DOSEMU, it should be fairly simple.

Create a named pipe.

On the DOS side, use a shell script to read one line from the pipe.

On the Linux side, prepare a DOS shell script or batch for the DOS side
to execute. (Remember the carriage returns where appropriate.) Then,
echo a crlf into the named pipe.

The read on the DOS side will now finish. Go execute the job. Then echo
your return code into a file, read another line from the named pipe, and
loop.

On the Linux side, echo another crlf into the named pipe; this waits for
the DOS side. Then read the return code from the file.


You might (with a sufficiently modern bash on the Linux side) write your
script with something like
#! /bin/bash
printf "%q " "$0" "$@" > script
echo -e '\r' > thepipe
echo Waiting for return code
echo -e '\r' > thepipe
read rc < rc
exit $rc
and link this to every command name you want to be able to execute.

On the DOS side,
:
while true
do
echo Waiting for command
read dummy < thepipe
sh script
echo $? > rc
read dummy < thepipe
done

Disclaimer: I haven't really done more than a quick test of named pipe
reading. I'm sure there are some subtilities here.

Andris Pavenis
2008-01-27 14:32:46 UTC
Permalink
Post by Ben Elliston
Post by DJ Delorie
Post by Joseph S. Myers
DJGPP,
Please don't deprecate this. It's actively used, but the test harness
doesn't run under DJGPP so testing it is difficult. I don't think
we've *ever* run the testsuite for it.
You can't cross-test, with DejaGnu running elsewhere?
Theoretically it maybe could possibly be done, but the main problem
is perhaps available manpower. I released DJGPP packages
of GCC for long time up to version 4.2.2 (native compiler
and for last versions also Linux to DJGPP cross-compiler RPM
packages).

I have also tried to build 4.3 snapshots as native compiler
for DJGPP, but run into trouble with broken DJGPP port of BASH (latest
we have is bash-2.0.5b), which prevented build to work for
libstdc++-v3. I tried to fix it, but there were still problems.
I don't know when I'll have time to fix them.

Additionally there is rather large set of patches I need to apply
for building GCC for DJGPP. I haven't had time get them in.

Andris
John David Anglin
2008-01-23 17:21:15 UTC
Permalink
Post by Joseph S. Myers
* parisc*-*-*, alias for hppa*-*-*. Also apparently an unused alias
handled by config.gcc that should move to config.sub if desired.
I'm happy to see this go. It's not checked for in the testsuite, etc.
Post by Joseph S. Myers
HP-UX is only being tested on hppa, not IA64.
I believe that Steve Ellcey is testing ia64-hpux but he doesn't usually
submit test results. He has been prohibited from making any contributions
in recent months by HP legal. They are reviewing the switch to GPL v3.

Dave
--
J. David Anglin ***@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Hans-Peter Nilsson
2008-01-24 00:51:12 UTC
Permalink
Post by Joseph S. Myers
There is good coverage for
bare-metal ELF targets, but none for bare-metal a.out and COFF targets
(perhaps we should consider deprecating all of those, on the
presumption that bare-metal use has moved to ELF and objcopy is likely
to be used in any case to produce a raw binary image; -pe targets are
not being tested either)
FWIW, I'd be fine with (even happy to) deprecate cris-aout.

brgds, H-P
Jan-Benedict Glaw
2008-01-24 02:07:08 UTC
Permalink
Post by Joseph S. Myers
* vax-*-bsd*
* vax-*-sysv*
* vax-*-ultrix*
I'll start looking into the NetBSD target. There are other bits
(OpenBSD and the non-BSD targets) but I won't work on those. It'll
take some time to get the environment right, but I hope to be able to
send some testresult in some days or weeks.

When will 4.3 be branched off?

MfG, JBG
--
Jan-Benedict Glaw ***@lug-owl.de +49-172-7608481
Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second :
Paul Koning
2008-01-24 15:25:01 UTC
Permalink
Joseph> ... There is good coverage for
Joseph> bare-metal ELF targets, but none for bare-metal a.out and
Joseph> COFF targets (perhaps we should consider deprecating all of
Joseph> those, on the presumption that bare-metal use has moved to
Joseph> ELF and objcopy is likely to be used in any case to produce a
Joseph> raw binary image...

I believe pdp11 (all OS flavors) is a.out. Is getting rid of COFF and
a.out considered a desirable thing to do? If so I'll look at what
that implies in pdp11.

paul
Joseph S. Myers
2008-01-24 17:49:40 UTC
Permalink
Post by Paul Koning
Joseph> ... There is good coverage for
Joseph> bare-metal ELF targets, but none for bare-metal a.out and
Joseph> COFF targets (perhaps we should consider deprecating all of
Joseph> those, on the presumption that bare-metal use has moved to
Joseph> ELF and objcopy is likely to be used in any case to produce a
Joseph> raw binary image...
I believe pdp11 (all OS flavors) is a.out. Is getting rid of COFF and
a.out considered a desirable thing to do? If so I'll look at what
that implies in pdp11.
Getting rid of generic *-*-aout* and *-*-coff*, where there are
corresponding ELF targets for the same CPU, is what I was suggesting might
be considered (and has not attracted any comments on the general idea).
This is not the same as getting rid of COFF and a.out altogether, because
of various other targets using those formats.

It is of course the case that various features in GCC work better with ELF
and DWARF than other formats (and LTO is being written to use libelf at
present, for example, although I imagine it may be extended to support
other file formats with the same raw data embedded in them in due course).
--
Joseph S. Myers
***@codesourcery.com
Ryan Mansfield
2008-01-29 16:06:09 UTC
Permalink
Post by Joseph S. Myers
Following my proposal for target architecture deprecations in 4.3
<http://gcc.gnu.org/ml/gcc/2008-01/msg00335.html>, I now propose the
following list of individual targets to deprecate, based on the same
methodology previously described. The patch to remove c4x and
deprecate the previously discussed target architectures crx, iq2000,
mt, stormy16 will be submitted shortly; the patch for the remaining
deprecations (only touching config.gcc and the release notes) will be
submitted later after any discussion.
* i[34567]86-*-nto-qnx*
Please do not deprecated this target. We intend to update this target
and post test results in the very near future.

Regards,

Ryan Mansfield
Nick Clifton
2008-01-23 21:01:47 UTC
Permalink
Hi Joseph,

Well the IQ2000 port is still of interest to us, and I am still happy
to maintain it, so here are some test results:

Test Run By nickc on Wed Jan 23 10:37:48 2008
Target is iq2000-unknown-elf
Host is i686-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
iq2000-sim
[...]
=== gcc Summary ===

# of expected passes 43656
# of unexpected failures 186
# of unexpected successes 1
# of expected failures 84
# of unresolved testcases 129
# of untested testcases 35
# of unsupported tests 395
/work/builds/gcc/current/iq2000-elf/gcc/xgcc version 4.3.0 20080123
(experimental) [trunk revision 131756] (GCC)
[...]
=== g++ Summary ===

# of expected passes 15563
# of unexpected failures 295
# of expected failures 81
# of unresolved testcases 121
# of unsupported tests 172
/work/builds/gcc/current/iq2000-elf/gcc/g++ version 4.3.0 20080123
(experimental) [trunk revision 131756] (GCC)

Cheers
Nick
Joseph S. Myers
2008-01-23 22:45:52 UTC
Permalink
Post by Nick Clifton
Hi Joseph,
Well the IQ2000 port is still of interest to us, and I am still happy
On that basis I've removed it from my deprecation list, but results need
to go to gcc-testresults in the form generated by contrib/test_summary (if
they are sent but get consistently rejected for being over 400k, that's a
bad sign for the maintainedness of a target). I checked the subject lines
of gcc-testresults messages since the start of 2007 (presuming them to be
in the standard form generated by contrib/test_summary) and then checked
for any mention in gcc-patches indicating a patch had been tested on a
target since the start of 2007; I did not look at gcc list archives at all
in determining which targets seemed to be actively tested, only
gcc-testresults and gcc-patches.
--
Joseph S. Myers
***@codesourcery.com
Joern Rennecke
2008-01-24 13:04:18 UTC
Permalink
Post by Joseph S. Myers
Of the others: arc, crx, iq2000, mt, pdp11, stormy16, I see no recent
testing or development. Joern Rennecke was intending to improve ARC
support but is listed as "Waiting for paperwork" in MAINTAINERS; is
there any news on that assignment?
It is still held up my legal matters; I am told, however, that this is now
handled with much higher priority than it was a year ago.
DJ Delorie
2008-01-24 21:20:59 UTC
Permalink
Post by Joseph S. Myers
* Any target with test results posted to gcc-testresults within the
past year,
I did a test run of the sh-elf test results script. There are so many
multilibs that the email is 437 Kb long. Still want it as-is?
Summary attached.


=== gcc Summary for sh-sim/-m4a-single-only ===

# of expected passes 44683
# of unexpected failures 73
# of unexpected successes 1
# of expected failures 86
# of unresolved testcases 92
# of untested testcases 35
# of unsupported tests 376

=== gcc Summary ===

# of expected passes 849104
# of unexpected failures 1066
# of unexpected successes 16
# of expected failures 1637
# of unresolved testcases 1854
# of untested testcases 665
# of unsupported tests 7144
/sata/dj/gnu/gcc/sh-elf/gcc/xgcc version 4.3.0 20080124 (experimental) [trunk revision 131776] (GCC)


=== g++ Summary for sh-sim/-m4a-single-only ===

# of expected passes 16696
# of unexpected failures 30
# of unexpected successes 2
# of expected failures 81
# of unresolved testcases 49
# of unsupported tests 162

=== g++ Summary ===

# of expected passes 317108
# of unexpected failures 559
# of unexpected successes 38
# of expected failures 1539
# of unresolved testcases 957
# of unsupported tests 3078
/sata/dj/gnu/gcc/sh-elf/gcc/testsuite/g++/../../g++ version 4.3.0 20080124 (experimental) [trunk revision 131776] (GCC)
Joseph S. Myers
2008-01-24 21:59:53 UTC
Permalink
Post by DJ Delorie
Post by Joseph S. Myers
* Any target with test results posted to gcc-testresults within the
past year,
I did a test run of the sh-elf test results script. There are so many
multilibs that the email is 437 Kb long. Still want it as-is?
sh-unknown-elf is already on the list of targets tested since the start of
2007, but I'm only counting those where the results reached
gcc-testresults successfully (so were under 400 Kb). Actively maintained
targets need a maintainer doing enough work on the results (fixing bugs
and arranging for inapplicable tests to be skipped or XFAILed) to get them
down below that size.
--
Joseph S. Myers
***@codesourcery.com
DJ Delorie
2008-01-24 22:50:24 UTC
Permalink
Actively maintained targets need a maintainer doing enough work on
the results (fixing bugs and arranging for inapplicable tests to be
skipped or XFAILed) to get them down below that size.
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily get the test results under 400k by
removing some of the multilibs, but I don't think that's a good idea.
My sh-elf test tests 38 multilibs, if I only test one that would be a
12k email, which would easily fit past the filters. Are we
artificially penalizing targets with many multilibs?

Also, while I'm not suggesting I be a maintainer for sh and h8300, if
I'm working on them and producing test results, should I send them in
anyway? I can always stop sending them when I stop working on them
(for whatever reason), but meanwhile, does that count against
deprecation?
Joseph S. Myers
2008-01-24 23:16:43 UTC
Permalink
Post by DJ Delorie
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily get the test results under 400k by
removing some of the multilibs, but I don't think that's a good idea.
My sh-elf test tests 38 multilibs, if I only test one that would be a
12k email, which would easily fit past the filters. Are we
artificially penalizing targets with many multilibs?
If results are being rejected without indicating the target is in terrible
shape, you could ask overseers to increase the size limit on
gcc-testresults.

I'm not actually convinced these long default multilib lists are a good
idea; if a user doesn't just want a single multilib for their processor,
the long generic list is likely to be wrong for them as well. sh has a
mechanism for selecting multilibs at configure time, and a more general
such mechanism would be good as well (for some targets such as GNU/Linux,
it would need to deal with SYSROOT_SUFFIX_SPEC and
SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note
some targets already generate SYSROOT_SUFFIX_SPEC automatically).
Post by DJ Delorie
Also, while I'm not suggesting I be a maintainer for sh and h8300, if
I'm working on them and producing test results, should I send them in
anyway? I can always stop sending them when I stop working on them
(for whatever reason), but meanwhile, does that count against
deprecation?
Anyone sending results for a target counts against deprecation. I didn't
even look at what version the results are for (although maybe in the 4.4
cycle we should only look at results for 4.3 or later).
--
Joseph S. Myers
***@codesourcery.com
DJ Delorie
2008-01-24 23:22:50 UTC
Permalink
Post by Joseph S. Myers
I'm not actually convinced these long default multilib lists are a
good idea;
If my goal was to write SH software, I'd agree. However, my goal is
to try to get the port into shape, so a long list is useful.
Internally, we use an even longer list, but the FSF sources don't
support (by default) all the multilibs we do.
Joe Buck
2008-01-24 23:25:29 UTC
Permalink
Post by Joseph S. Myers
Post by DJ Delorie
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily get the test results under 400k by
removing some of the multilibs, but I don't think that's a good idea.
My sh-elf test tests 38 multilibs, if I only test one that would be a
12k email, which would easily fit past the filters. Are we
artificially penalizing targets with many multilibs?
If results are being rejected without indicating the target is in terrible
shape, you could ask overseers to increase the size limit on
gcc-testresults.
Or the test script could be fixed to pre-scan the message instead of just
piping it to a mailer. If its size exceeds some limit (say 300k), the
mail could be replaced by a shortened form, giving only the total numbers
of failures with a big message at the beginning indicating that the
message was truncated because of the massive number of failures.
DJ Delorie
2008-01-24 23:30:48 UTC
Permalink
Post by Joe Buck
message was truncated because of the massive number of failures.
Or massive number of multilibs :-)
Hans-Peter Nilsson
2008-01-27 06:11:52 UTC
Permalink
Post by DJ Delorie
Post by Joe Buck
message was truncated because of the massive number of failures.
Or massive number of multilibs :-)
Let me humbly and pragmatically suggest testing with just the
default multilib (or a much smaller subset than all you do) once
in a while.

Fixing test_summary to prune identical results for multilibs
would also be a solution.

brgds, H-P
Joel Sherrill
2008-01-25 14:55:52 UTC
Permalink
Post by Joseph S. Myers
Post by DJ Delorie
At the moment, I'm working on getting sh, h8300, and m32c in shape for
4.3 (or future). I can easily get the test results under 400k by
removing some of the multilibs, but I don't think that's a good idea.
My sh-elf test tests 38 multilibs, if I only test one that would be a
12k email, which would easily fit past the filters. Are we
artificially penalizing targets with many multilibs?
If results are being rejected without indicating the target is in terrible
shape, you could ask overseers to increase the size limit on
gcc-testresults.
I'm not actually convinced these long default multilib lists are a good
idea; if a user doesn't just want a single multilib for their processor,
the long generic list is likely to be wrong for them as well.
Depends on the user. For *-rtems*, we build the OS proper
multilib and produce libraries. The user links that against
a Board Support Package and their application. We are
careful to justify each multilib variant in the RTEMS targets
since it does lead to longer compile times and longer tool
download times when our users install.

Here is a count of the multilib variants for the targets we
have pre-compiled RTEMS for. Note that all are using gcc
4.2.2 except AVR (4.0.4) and tic4x (3.4.6).

arm-rtems4.9 3
avr-rtems4.9 4
bfin-rtems4.9 1
h8300-rtems4.9 7
i386-rtems4.9 6
m68k-rtems4.9 15
mips-rtems4.9 6
powerpc-rtems4.9 15
sh-rtems4.9 11
sparc-rtems4.9 4
tic4x-rtems4.9 4

So you can see that even though we haven't figured out
how to run the GCC testsuite when linked against RTEMS,
we do have "good news" on a number of targets.

With some help from a gcc tester, we should be able to
start reporting results on many of the above using
simulators.
Post by Joseph S. Myers
sh has a
mechanism for selecting multilibs at configure time, and a more general
such mechanism would be good as well (for some targets such as GNU/Linux,
it would need to deal with SYSROOT_SUFFIX_SPEC and
SYSROOT_HEADERS_SUFFIX_SPEC as well as the usual multilib variables; note
some targets already generate SYSROOT_SUFFIX_SPEC automatically).
Post by DJ Delorie
Also, while I'm not suggesting I be a maintainer for sh and h8300, if
I'm working on them and producing test results, should I send them in
anyway? I can always stop sending them when I stop working on them
(for whatever reason), but meanwhile, does that count against
deprecation?
Anyone sending results for a target counts against deprecation. I didn't
even look at what version the results are for (although maybe in the 4.4
cycle we should only look at results for 4.3 or later).
--
Joseph S. Myers
Nick Clifton
2008-01-25 11:33:05 UTC
Permalink
Hi Joseph,

I have posted some results for the xstormy16-elf target. They are not great
(614 failures) but I do hope that this can target can be removed from the
potential deprecations list.

Cheers
Nick
Loading...