Re: [PATCH] PR target/48904 x86_64-knetbsd-gnu missing defs
On Thu, Apr 30, 2015 at 11:58:09PM +0200, Bernhard Reutner-Fischer wrote:
> On April 30, 2015 5:53:02 PM GMT+02:00, Jeff Law <law@redhat.com> wrote:
> >On 04/30/2015 01:58 AM, Bernhard Reutner-Fischer wrote:
> >> Hi,
> >>
> >> On 30 April 2015 at 07:00, Jeff Law <law@redhat.com> wrote:
> >>> On 04/29/2015 02:01 AM, Bernhard Reutner-Fischer wrote:
> >>>>
> >>>> 2012-09-21 H.J. Lu <hongjiu.lu@intel.com>
> >>>>
> >>>> PR target/48904
> >>>> * config.gcc (x86_64-*-knetbsd*-gnu): Add
> >i386/knetbsd-gnu64.h.
> >>>> * config/i386/knetbsd-gnu64.h: New file
> >>>
> >>> OK. Please install on the trunk.
> >>
> >> hmz, according to https://www.debian.org/ports/netbsd/ the debian
> >> knetbsd port is abandoned since about 2002.
> >> If this is true (please confirm) then we should probably remove
> >knetbsd from
> >> - upstream config repo
> >> - GCC
> >> - binutils-gdb
> >>
> >> instead of the above patchlet.
> >> This would work equally well for me WRT config-list.mk builds..
> >> [I should have checked this earlier, sorry..]
> >Given what Guillem indicated, I'd support removal.
> >
> >It's often the case that we mark it as deprecated and issue an explicit
> >
> >error if someone tries to build the port. That seems wise here.
>
> I will apply the abovementioned patch ASAP and let somebody else with janitorial spare cleanup cycles propose removal of
> *-knetbsd-* then.
> Given previous discussion in https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00582.html someone may also be in a position to remove *-openbsd3-* support, FWIW.
> I personally cannot take care of these due to limited (essentially non-existing ;) spare time.
I'll try to get to it before the end of stage 1. Its pretty easy
really, you just add the triple you want to obsolete to the switch in
config.gcc at about line 240, and then wait for the next release.
btw thanks for cleaning up config-list.mk :)
> Same, BTW for Ultrix support which was officially removed from GCC last cycle, IIRC -- unless config entries are meant to be sticky from a GNU tool chain support POV per design/decision?
It looks like most of the ultrix references are in config.guess /
config.sub / configure so from upstream repositories. THere's a few
references in gcc/doc/ that could probably be cleaned up, and a little
bit of something in fixincludes I think.
Trev
>
> Either way, cannot clean these up properly ATM and not familiar with those policies, so punting for now..
>
> Cheers,
> >
> >jeff
>
>
Reply to: