Re: [RFC] A policy for supported ports and targets

[Richard Sandiford <rsandifo at redhat dot com>]

Your main concern seems to be the burden that "unmaintained" ports place
on the maintainability of target-independent parts of gcc.  And I bet
many folks agree that's a problem.  It's bad when an old or minor port
stops developers from improving the rest of gcc.

On the other hand, if an old port _isn't_ stopping developers from doing
that, I don't see that it matters too much whether the port happens to
meet some particular standard of being "actively maintained".

So I don't think proposals like this:

> Ports can be obsoleted when the port is no longer maintained.  A port is
> considered maintained if all of the following conditions are met:
> 1) Test results are reported to gcc-testresults by the port maintaine in
>    every stage 3 of the release cycle.  The release notes will point to
>    the latest reported test results before the release.
> 2) The port has been updated from old interfaces/infrastructure before
>    the old infrastructure is removed (as per Proposal 2).
> 3) backends.html is up-to-date.
> Obsolete ports will be removed in the next minor release unless the port
> maintainer resumes active maintenance of the port such that it can be
> considered a maintained port again.

are the right way to go.  It seems unlikely such rules & procedures will
really help improve maintainability in practice.  Especially since it's
going to be quite easy to meet these requirements and still have an
awkward or outdated port that goes "unmaintained" the rest of the time.

On the other hand, points like (1) would probably end up being used to
browbeat maintainers and lead to unnecessary bad feeling.  It's not like
you or I are on the edge of our seats waiting for the next set of ip2k
or fr30 results.  And even if such results were posted every day, it
wouldn't make the ports any more or less of a burden when changing
the rest of gcc.

Why not just have a general principle that, if some port is stopping a
target-independent improvement to gcc, it can sometimes be OK to make
the improvement anyway?  To be decided on a case-by-base basis.  We've
already seen an analagous situation with tree-ssa and Ada.

And, of course, we continue to deprecate ports on a case-by-case basis,
after a bit of discussion about whether it's the right thing to do.
IMO, that's far better than the kind of semi-automatic system
envisonaged by your proposal above.

To respond to a few specific points:

Your message listed:

> old scheduler model              x1             x         x
> define_peephole        x              x                    
> not define_constant    x              x                    

as bad things for a port to have.  But the lack of define_constants
in *.md has no impact at all on the general gcc populace.  And I can't
remember the last time that the presence of the target-independent
define_peephole code caused problems to ports that don't use it.
Likewise the old scheduler model.

> So for 3 out of seven ports, 4 (more than half of them!) use one or more
> unofficically obsoleted interfaces (where both cris and ip2k don't have
> a scheduler description _at_all_, which basically means they implicitly
> use the old pipeline description),

This is a red herring.  If the port doesn't have a scheduling description,
it's hardly standing in the way of better scheduling code.

> An an external tree exists that is better maintained, but in the mean
> time, the FSF GCC 3.4 was released with a completely broken ip2k port.

But how many gcc developers _knew_ about the state of the ip2k backend
before 3.4.0 was released?  And how many cared?  Very few, I bet.
That indicates to me that the ip2k port wasn't hampering development
very much.

You might be concerned about other things too, like whether it's good
for users to have the port in the tree when it can be badly broken like
this.  But I think gcc developers who never use ip2k are the last people
who should be making judgements about what's good for ip2k users.

I don't think it's too unreasonable for port maintainers to say to
their users: "Don't use gcc 3.4.  The last good release was 3.3.x.
We'll soon be doing work on 3.5 and we'll let you know when it's
done." _provided that_ such an attitude doesn't affect other ports.
(Not that I'm saying that's what happened in this case.  It's just
a hypothetical situation.)

Remember that gcc changes very quickly, and that ports like x86, amd64
and powerpc have the benefit of many people who are prepared to update
them.  When such updates are left to just one person, it's much more of
a burden, and it might take more time to bring the port up to date.
I don't think it's helpful to impose a fixed time period on that.
(Provided, again, that such an attitude doesn't affect other ports.)

> These proposals come from my personal feelings that we have too many
> ports that are undertested and improperly maintained.  Many of those
> ports don't even support the GNU system.  So I don't see why those
> ports should be in the FSF tree.

By "GNU system", do you mean the GNU operating system?  If so, there
are many embedded ports that can't hope to run the GNU OS.  It's still
possible to run entirely free software on them (using, e.g., newlib &
libgloss).

Richard