Re: GCC policy on deprecating and removing targets

[Jeff Law <law at redhat dot com>]

On 11/20/2017 10:26 AM, mark.reinhold@oracle.com wrote:
> 2017/11/17 23:34:31 -0800, Andrew Haley <aph@redhat.com>:
>> On 18/11/17 01:44, Jeff Law wrote:
>>> On 11/17/2017 02:20 PM, mark.reinhold@oracle.com wrote:
>>>> Is https://gcc.gnu.org/wiki/TargetDeprecationFAQ the authoritative
>>>> definition of the policy for deprecating and then removing support
>>>> for specific targets?  If not, is there a more recent document?
>>>> (That wiki page was last updated in 2008.)
>>>
>>> It's still reasonably accurate.  We tend to have folks doing a bit wider
>>> scale testing than in the past, so for example you may find references
>>> to myself or someone else testing some target that in reality is
>>> probably ready for deprecation.  So we're not likely to be as strict on #1.
> 
> Thanks for the confirmation.
> 
>>> Are you going to suggest deprecating a particular target or are you
>>> trying to keep a particular target from being deprecated? :-)
>>
>> I suspect that Mark is looking for inspiration.  We're transitioning
>> OpenJDK to something more like a typical free-software project, and
>> GCC has a similar structure of front- and back-ends, and has
>> demonstrated the ability to scale as a project.
> 
> Exactly.  OpenJDK has reached the point where we have a variety of ports.
> Some are very actively maintained, some are less so, and some are on the
> verge of abandonment.  It's time to discuss and agree on what it means
> to maintain a port, and what the process is for proposing to remove one
> that's no longer maintained.
So probably the biggest thing in the GCC space is the announce
deprecation in release X and actual removal in release X+1.  That gives
folks a year to complain and potentially resurrect any particular port
or feature.

It's pretty rare these days to have a port that doesn't build as we've
worked hard to eliminate conditional compilation and we have tools that
will build the vast majority of ports up to a particular point (and
certain developers regularly use those tools).  However that does
nothing to verify that a port can generate code or that the code is even
close to correct.

I've actually got a jenkins based builder here that takes the next step
and verifies that at least one target within each cpu family can
generate code.  I'm actually going to use the results from that to
suggest port deprecations for gcc-8 :-)  That work shows there's a
couple cpu families where the port can't generate code for GCC's core
library (libgcc) and thus nobody is using those targets.

Hopefully for gcc-9 I can extend that work to include a level of
simulator testing for the embedded targets.  I certainly won't be
tracking regressions or anything like that, but instead just looking to
see if the generated code is generally runnable or not.

Jeff