This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Deprecate SH5/SH64
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: David Edelsohn <dje dot gcc at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Date: Mon, 21 Sep 2015 14:52:15 +0900
- Subject: Re: Deprecate SH5/SH64
- Authentication-results: sourceware.org; auth=none
- References: <DB2C9AFC-A5C6-4540-B503-E6449B1B79E2 at t-online dot de> <CAGWvnykY4-fqaWzFhYxNDgw-P13w3nUF5vNpRjJKnhkiLTVy3w at mail dot gmail dot com> <55D37C5F dot 6040308 at redhat dot com>
On Tue, 2015-08-18 at 12:41 -0600, Jeff Law wrote:
> On 08/18/2015 11:11 AM, David Edelsohn wrote:
> > On Tue, Aug 18, 2015 at 1:00 PM, Oleg Endo <oleg.endo@t-online.de>
> > wrote:
> >> Hi all,
> >>
> >> Kaz and I have been discussing the SH5/SH64 status, which is part
> >> of the SH port, every now and then. To our knowledge, there is no
> >> real hardware available as of today and we don't think there are
> >> any real users for a SH5/SH64 toolchain out there. Moreover, the
> >> SH5/SH64 parts of the SH port haven't been touched by anybody for a
> >> long time. The only exception is occasional ad-hoc fixes for bug
> >> reports from people who build GCC for every architecture that is
> >> listed in the Linux kernel. However, we don't actually know
> >> whether code compiled for SH5/SH64 still runs at an acceptable
> >> level since nobody has been doing any testing for that architecture
> >> for a while now.
> >>
> >> If there are no objections, we would like to deprecate SH5/SH64
> >> support as of GCC 6.
> >>
> >> Initially this would include an announcement on the changes page
> >> and the removal of any documentation related to SH5/SH64. After
> >> GCC 6 we might start removing configure options and the respective
> >> code paths in the target.
> >
> > +1
> Works for me based on what I've heard independently about sh5 hardware
> situation.
>
>
> Frankly, I think we should be more aggressive about this kind of
> port/variant pruning across the board.
I have committed the announcement for the GCC 6 page
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html
Cheers,
Oleg