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

[Richard Sandiford <rsandifo at redhat dot com>]

"S. Bosscher" <S.Bosscher@student.tudelft.nl> writes:
> Yes that is my main concern.  But only part of it.  The other concern
> is that many ports in the FSF tree are simply broken, so there is little
> point in releasing them in the FSF gcc.  It is as much about quality and
> responsability as it is about maintainability.

But my main point on that front was: ports tend to get as much attention
as they need to in order to satisfy the user community for that port.
I don't think we need to impose new rules to "force" it to happen.

Yes, in some cases, the port may be completely broken for a while.
But if you're not a user of that port, and that port isn't interfering
with your gcc development, why does it matter?  So we come back to the
main point about ports interfering with other people's gcc work.

> So you're saying it is unreasonable to ask of a port maintainer to test 
> his/her port every now and then?

No, I'm just saying adding new rules along the lines of "you must post
results between date X and date Y" won't help improve the maintainability
of target-independent parts of gcc.  My message was focused specifically
on the maintainability question.

> [ <teaser>
>   For example, I would like to propose to make the old pipeline
>   description obsolete for GCC 3.5.  You'll hate me an object
>   because MIPS still uses it.  But MIPS is basically the only port
>   that still uses it (and SH, but a new SH5 description already
>   exists, so...).  And there you are!  Even though the new pipeline
>   description has been around for more than 2 years in the FSF tree
>   (and even longer inside RedHat, it seems), we may end up dragging
>   around the old description for at least another two years.
>   </teaser> ;-) ]

But is the presence of the old pipeline description interfering
with your work?  Do you have some scheduling changes that you'd
like to make, but that are significantly harder while the old
define_function_unit stuff is there?

I think we have to be careful to divide improvements to gcc _functionality_
from code clean-up.  If an old feature is standing in the way of progress
on some other feature, and an alternative has been around for some time,
then IMO it's reasonable to break the ports that still use the old feature.

If, on the other hand, someone has an itch to remove a feature in the
name of code cleaniness, but not because it's blocking anything specific,
then that clean-up should include updating the backends.  With a suitably
pragmatic approach to approval, you wouldn't necessarily have to run
a full testsuite run for each backend.  Things like c-torture assembly
comparison should be fine for certain changes.  A "reasonable attempt"
should be enough.

> OTHO, define_peephole is blocking an infrastructure improvement, namely
> peephole2.

I don't see what you mean here.  Why is the existence of define_peephole
blocking improvements to ports that use define_peephole2?

> True.  But a port without a scheduling description relies on the fact
> that insns with no define_function_unit automatically get a latency of 1.

I tend to think that they don't rely on anything at all.  I.e., that the
lack of a scheduling description implies that the port maintainer doesn't
care about scheduling.

>> That indicates to me that the ip2k port wasn't hampering development
>> very much.
>
> But the quality of the release was worse for this particular port.  We
> are making a promise that gcc is high-quality, yet we're shipping a port
> that is completely broken,

No we're not!  At least not on those terms.  No-one every promised that
3.4 would be a high-quality ip2k release.  And of course there's the
usual disclaimer:

--------
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--------

>> 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.
>
> So you're saying it's fine to ship a compiler that we know to be broken
> like that, and, mind you, not even mentioning it in the release notes?

Well, if you _know_ it to be broken, you can mention it in the release
notes if you want.  And that would obviously be a helpful thing to do.
I thought the point of your rule was that we don't know whether some
ports are broken or not.

> These proposals are not to bash port maintainers.  It's just as much the
> responsibility of other developers who want to move ahead with some
> improvement to help out with updating the existing ports.  But again, it
> should be the responsibility of the port maintainer to start this work.
> After all, for many targets nobody but the port maintainer knows enough
> about the internals of the port to work on it.

Agreed.

I probably wasn't very clear, but my attitude to maintainability thing
is basically this...  The responsibility of keeping a port working should
lie almost exclusively with the port maintainer.  If there is general
agreement that a gcc patch is right in principle, but it happens to
break a particular port, then IMO, it's up to the port maintainer,
not the patch submitter, to fix it.  That applies to both bug fixes
and new infrastructure.

I get the feeling that the current patch submission rules don't work
like that.  There seems to be an attitude that, if your patch breaks
a particular target, it's your responsibility to fix it.

My main point was that: if the number of targets is proving a burden,
it would be better to relax the strict patch submission rules rather
than come up with yet more rules.  I guess I'd just like to see a
more pragmatic approach.  (Which, IMO, is what we already have when
it comes to deprecation.  We just need the patch submission side
to match.)

>> 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.
>
> No fixed time period is what we have now, and you can see it simply does
> not work

Not sure I do see that, really. ;)

Richard