Target deprecations for 4.6

Target deprecations for 4.6

[Joseph S. Myers]

There have been some discussions of possible target deprecations in 4.6, 
including a list I sent at 
<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01165.html>, but no 
particular conclusions.  Here is a concrete list I propose for deprecation 
in 4.6; please send any other suggestions, or say if you wish to volunteer 
to maintain one of these targets to avoid deprecation (and start sending 
patches and test results in that case; m68hc11 has a nominal maintainer, 
but no test results after July 2007).

* ARC (arc-*) (unmaintained for a long time).

* M68hc1x (m68hc11-*-*, m6811-*-*, m68hc12-*-*, m6812-*-*) (see 
<http://gcc.gnu.org/ml/gcc/2011-01/msg00359.html>).

* Interix (i[34567]86-*-interix3*) (see PR 47096).

* Generic ARM PE (arm-*-pe* not matching arm*-wince-pe*).

* MCore PE, and with it svr3.h (mcore-*-pe*).

* i[34567]86-*-pe (an alias for Cygwin in config.gcc rather than 
config.sub, so not effectively treated as an alias elsewhere).

* M68K uClinux old ABI (m68k-*-uclinuxoldabi*).

* a.out NetBSD (arm*-*-netbsd* not matching arm*-*-netbsdelf*, 
i[34567]86-*-netbsd* not matching i[34567]86-*-netbsdelf*, vax-*-netbsd* 
not matching vax-*-netbsdelf*).

* SH SymbianOS (sh-*-symbianelf*) (see PR 47119).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[Dave Korn]

On 28/01/2011 01:11, Joseph S. Myers wrote:

> * i[34567]86-*-pe (an alias for Cygwin in config.gcc rather than 
> config.sub, so not effectively treated as an alias elsewhere).

  Makes sense to me, thank you.  (I've never heard of anyone using it, I don't
think it would even matter if you just removed it as obsolete historical cruft.)

    cheers,
      DaveK

Re: Target deprecations for 4.6

[Gerald Pfeifer]

On Fri, 28 Jan 2011, Joseph S. Myers wrote:
> Here is a concrete list I propose for deprecation in 4.6; please send 
> any other suggestions, or say if you wish to volunteer to maintain one 
> of these targets to avoid deprecation

Thanks for doing this, Joseph!

I am not sure how to formally handle this, but we are removing the last 
bits of support for FreeBSD 1.x with GCC 4.6.  I am pretty confident this 
has not worked for years (that platform did not have dynamic libraries),
but there was a bit of machinery that's on it's way out.

Gerald

Re: Target deprecations for 4.6

[Joseph S. Myers]

On Mon, 31 Jan 2011, Gerald Pfeifer wrote:

> On Fri, 28 Jan 2011, Joseph S. Myers wrote:
> > Here is a concrete list I propose for deprecation in 4.6; please send 
> > any other suggestions, or say if you wish to volunteer to maintain one 
> > of these targets to avoid deprecation
> 
> Thanks for doing this, Joseph!
> 
> I am not sure how to formally handle this, but we are removing the last 
> bits of support for FreeBSD 1.x with GCC 4.6.  I am pretty confident this 
> has not worked for years (that platform did not have dynamic libraries),
> but there was a bit of machinery that's on it's way out.

My inclination would be to move the

*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
  # This is the place-holder for the generic a.out configuration
  # of FreeBSD.  No actual configuration resides here since
  # there was only ever a bare-bones ix86 configuration for
  # a.out and it exists solely in the machine-specific section.
  # This place-holder must exist to avoid dropping into
  # the generic ELF configuration of FreeBSD (i.e. it must be
  # ordered before that section).
  ;;

case up to

# Unsupported targets list.  Do not put an entry in this list unless
# it would otherwise be caught by a more permissive pattern.  The list
# should be in alphabetical order.

so that those cases get an error at configure time, and close PR 47094.  
Addressing PR 47123 in a similar way would also be good.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[Gerald Pfeifer]

On Sun, 30 Jan 2011, Joseph S. Myers wrote:
> My inclination would be to move the
> 
> *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
>   # This is the place-holder for the generic a.out configuration
>   # of FreeBSD.  No actual configuration resides here since
>   # there was only ever a bare-bones ix86 configuration for
>   # a.out and it exists solely in the machine-specific section.
>   # This place-holder must exist to avoid dropping into
>   # the generic ELF configuration of FreeBSD (i.e. it must be
>   # ordered before that section).
>   ;;
> 
> case up to

You mean like this?  Not sure who would approve something like this,
technically.  Shall I got ahead and commit this?


Gerald


2011-02-01  Gerald Pfeifer  <gerald@pfeifer.com>

	* config.gcc (*-*-freebsd[12], *-*-freebsd[12].*, *-*-freebsd*aout*):
	Move to the unsupported targets list.

Index: config.gcc
===================================================================
--- config.gcc	(revision 169463)
+++ config.gcc	(working copy)
@@ -246,6 +246,8 @@
  | pdp11-*-bsd				\
  | sparc-hal-solaris2*			\
  | thumb-*-*				\
+ | *-*-freebsd[12] | *-*-freebsd[12].*	\
+ | *-*-freebsd*aout*			\
  | *-*-linux*aout*			\
  | *-*-linux*coff*			\
  | *-*-linux*libc1*			\
@@ -480,15 +482,6 @@
     "" | yes | posix) thread_file='posix' ;;
   esac
   ;;
-*-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
-  # This is the place-holder for the generic a.out configuration
-  # of FreeBSD.  No actual configuration resides here since
-  # there was only ever a bare-bones ix86 configuration for
-  # a.out and it exists solely in the machine-specific section.
-  # This place-holder must exist to avoid dropping into
-  # the generic ELF configuration of FreeBSD (i.e. it must be
-  # ordered before that section).
-  ;;
 *-*-freebsd*)
   # This is the generic ELF configuration of FreeBSD.  Later
   # machine-specific sections may refine and add to this

Re: Target deprecations for 4.6

[Joseph S. Myers]

On Tue, 1 Feb 2011, Gerald Pfeifer wrote:

> On Sun, 30 Jan 2011, Joseph S. Myers wrote:
> > My inclination would be to move the
> > 
> > *-*-freebsd[12] | *-*-freebsd[12].* | *-*-freebsd*aout*)
> >   # This is the place-holder for the generic a.out configuration
> >   # of FreeBSD.  No actual configuration resides here since
> >   # there was only ever a bare-bones ix86 configuration for
> >   # a.out and it exists solely in the machine-specific section.
> >   # This place-holder must exist to avoid dropping into
> >   # the generic ELF configuration of FreeBSD (i.e. it must be
> >   # ordered before that section).
> >   ;;
> > 
> > case up to
> 
> You mean like this?  Not sure who would approve something like this,

Yes, like that.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[Nathan Froyd]

On Fri, Jan 28, 2011 at 01:11:10AM +0000, Joseph S. Myers wrote:
> Here is a concrete list I propose for deprecation in 4.6; please send
> any other suggestions...

score-* doesn't have a maintainer and score-elf couldn't build libgcc
last I checked (it was also mentioned in your previous message).

crx-*?  crx-elf can't built libgcc, and hasn't been able to for a while.

-Nathan

Re: Target deprecations for 4.6

[Joseph S. Myers]

On Fri, 11 Feb 2011, Nathan Froyd wrote:

> On Fri, Jan 28, 2011 at 01:11:10AM +0000, Joseph S. Myers wrote:
> > Here is a concrete list I propose for deprecation in 4.6; please send
> > any other suggestions...
> 
> score-* doesn't have a maintainer and score-elf couldn't build libgcc
> last I checked (it was also mentioned in your previous message).
> 
> crx-*?  crx-elf can't built libgcc, and hasn't been able to for a while.

Since the main deprecation patches are now in, feel free to send further 
patches (to config.gcc and the release notes).

I can't quite figure out what the score people are up to, but it doesn't 
appear to involve a simultaneously maintained set of upstream components 
that are usable together in their current upstream forms; they got Linux 
kernel support upstream in 2009 (and don't seem to have maintained it much 
since then), some time after they got GCC support upstream (and then 
stopped maintaining it).

There may also be subtargets or target-specific features worth considering 
for deprecation (e.g. ARM -mwords-little-endian was mentioned in a 
previous cleanup discussion).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[David Edelsohn]

On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:

> I can't quite figure out what the score people are up to, but it doesn't
> appear to involve a simultaneously maintained set of upstream components
> that are usable together in their current upstream forms; they got Linux
> kernel support upstream in 2009 (and don't seem to have maintained it much
> since then), some time after they got GCC support upstream (and then
> stopped maintaining it).

The SCORE port was accepted and maintainers appointed with the
understanding that lack of maintenance would lead to rapid deprecation
and removal.

I would suggest directly sending a message to the last contacts and
any other contact email address for SCORE that the port must function
and test results posted or it will be deprecated and removed.  That
the GCC community needs to see action, not future promises.

- David

Re: Target deprecations for 4.6

[Nathan Froyd]

On Sat, Feb 12, 2011 at 08:11:07AM -0500, David Edelsohn wrote:
> On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> > appear to involve a simultaneously maintained set of upstream components
> > that are usable together in their current upstream forms; they got Linux
> > kernel support upstream in 2009 (and don't seem to have maintained it much
> > since then), some time after they got GCC support upstream (and then
> > stopped maintaining it).
> 
> The SCORE port was accepted and maintainers appointed with the
> understanding that lack of maintenance would lead to rapid deprecation
> and removal.
> 
> I would suggest directly sending a message to the last contacts and
> any other contact email address for SCORE that the port must function
> and test results posted or it will be deprecated and removed.  That
> the GCC community needs to see action, not future promises.

Patch for adding score-* and crx-* to obsolete ports below.  Last
contact for SCORE and current crx maintainer CC'd.

OK to commit?

-Nathan

	* config.gcc: Declare score-* and crx-* obsolete.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..0f7050d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -237,6 +237,7 @@ case ${target} in
  | alpha*-*-gnu*			\
  | arm*-*-netbsd*			\
  | arm-*-pe*				\
+ | crx-*				\
  | i[34567]86-*-interix3*		\
  | i[34567]86-*-netbsd*			\
  | i[34567]86-*-pe			\
@@ -247,6 +248,7 @@ case ${target} in
  | m68k-*-uclinuxoldabi*		\
  | mcore-*-pe*				\
  | powerpc*-*-gnu*			\
+ | score-*				\
  | sh*-*-symbianelf*			\
  | vax-*-netbsd*			\
  )

Re: Target deprecations for 4.6

[Douglas B Rupp]

Joseph S. Myers wrote:

> * Interix (i[34567]86-*-interix3*) (see PR 47096).

I would appreciate it if you could leave Interix. I'll take the 
responsibility to get it working.

Re: Target deprecations for 4.6

[Joseph S. Myers]

On Mon, 14 Feb 2011, Douglas B Rupp wrote:

> Joseph S. Myers wrote:
> 
> > * Interix (i[34567]86-*-interix3*) (see PR 47096).
> 
> I would appreciate it if you could leave Interix. I'll take the responsibility
> to get it working.

The deprecation patch has gone in.  That means that your patch to get it 
working should include the undeprecation patch to config.gcc (as well as 
the associated changes to the 4.6 release notes); there's no point 
undeprecating before then since the target doesn't actually build at all.  
Hopefully the SC can consider you as a potential Interix target maintainer 
based on your message.  If your patch isn't in by the time 4.6 branches 
but is expected soon afterwards we can always leave the target present but 
deprecated in trunk when the other deprecated targets are removed.

Getting it working means not just making it possible to build a cross 
compiler to Interix target but getting it to build cleanly with -Werror: 
either making native bootstrap work, or making building a cross compiler 
with --enable-werror-always work, starting from a native build of current 
trunk as the native compiler used to build the cross compiler.

There are four different target configuration headers used for Interix 
(i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h).  Since 
there's only one Interix target present in GCC, the abstraction implied by 
four headers - some of which override macros defined in each other, 
meaning some macro definitions are effectively dead - is rather bogus.  I 
advise combining these four headers into one so that it is more readily 
possible to see what target configuration actually ends up being in effect 
for this target.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[Douglas B Rupp]

Joseph S. Myers wrote:
> On Mon, 14 Feb 2011, Douglas B Rupp wrote:
> 
>> Joseph S. Myers wrote:
>>
>>> * Interix (i[34567]86-*-interix3*) (see PR 47096).
>> I would appreciate it if you could leave Interix. I'll take the responsibility
>> to get it working.
> 
> The deprecation patch has gone in.  That means that your patch to get it 
> working should include the undeprecation patch to config.gcc (as well as 
> the associated changes to the 4.6 release notes); there's no point 
> undeprecating before then since the target doesn't actually build at all.  
> Hopefully the SC can consider you as a potential Interix target maintainer 
> based on your message.  If your patch isn't in by the time 4.6 branches 
> but is expected soon afterwards we can always leave the target present but 
> deprecated in trunk when the other deprecated targets are removed.

I'll accept appointment as maintainer, if the SC so decides.

> 
> Getting it working means not just making it possible to build a cross 
> compiler to Interix target but getting it to build cleanly with -Werror: 
> either making native bootstrap work, or making building a cross compiler 
> with --enable-werror-always work, starting from a native build of current 
> trunk as the native compiler used to build the cross compiler.

Thanks for clearing up that procedure.  The binutils bits have rotted 
badly, so it will take some work to get native bootstrap working again. 
I'll try the latter procedure.

> 
> There are four different target configuration headers used for Interix 
> (i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h).  Since 
> there's only one Interix target present in GCC, the abstraction implied by 
> four headers - some of which override macros defined in each other, 
> meaning some macro definitions are effectively dead - is rather bogus.  I 
> advise combining these four headers into one so that it is more readily 
> possible to see what target configuration actually ends up being in effect 
> for this target.
> 

Agreed. Fyi the subsystem variants supported by MS are 32bit and 64bit 
x86 and 64bit ia64.  I don't the see much point in putting work into an 
ia64 Interix compiler at this time.  But maybe two headers for x86: 32 
and 64bit, if it makes sense to have them split out.

Re: Target deprecations for 4.6

[Joseph S. Myers]

On Tue, 15 Feb 2011, Douglas B Rupp wrote:

> > There are four different target configuration headers used for Interix
> > (i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h).  Since
> > there's only one Interix target present in GCC, the abstraction implied by
> > four headers - some of which override macros defined in each other, meaning
> > some macro definitions are effectively dead - is rather bogus.  I advise
> > combining these four headers into one so that it is more readily possible to
> > see what target configuration actually ends up being in effect for this
> > target.
> 
> Agreed. Fyi the subsystem variants supported by MS are 32bit and 64bit x86 and
> 64bit ia64.  I don't the see much point in putting work into an ia64 Interix
> compiler at this time.  But maybe two headers for x86: 32 and 64bit, if it
> makes sense to have them split out.

I'd think that ideally you'd want one configuration that works with both 
-m32 and -m64 (so the only difference between i686-interix and 
x86_64-interix is which is the default), though I don't know how practical 
that is.

Anyway, as long as only one Interix version is supported by GCC the 
distinction between "Interix" and "Interix 3" headers is meaningless.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target deprecations for 4.6

[Nathan Froyd]

On Mon, Feb 14, 2011 at 09:41:50AM -0800, Nathan Froyd wrote:
> Patch for adding score-* and crx-* to obsolete ports below.  Last
> contact for SCORE and current crx maintainer CC'd.

I have committed this patch.  The crx maintainer (Pompapathi Gadad)
contacted me via private mail and indicated it would be OK to obsolete
the crx port.  Following David and Joseph's comments, along with the
lack of activity for SCORE targets for the past several years[*], I think
the SCORE port is overdue.

I will commit a patch to the website shortly.

-Nathan

[*] Though I think some of the other backends might qualify under the
inactivity criterion.  We can save those battles for 4.7, though...