Convert legacy m68k options to .opt aliases

Similar to <http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00265.html>,
this patch converts legacy m68k options for non-ColdFire CPUs into
aliases for the corresponding -mcpu= options.  (Note that -mcpu32 is
an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old
code in m68k_handle_option.)  This significantly simplifies the
multilibs code in t-mlibs, since it no longer needs to handle those
old-style options (and all cases where two -mcpu= options get the same
multilib are already handled by the generic logic there rather than
needing to be listed specially).  The requirement for binutils 2.17 or
later (to support these options to the assembler) is documented.

Tested building cc1 and xgcc for cross to m68k-elf.  Will commit to
trunk in the absence of target maintainer objections.

2011-04-06  Joseph Myers  <joseph@codesourcery.com>

	* config/m68k/m68k.c (m68k_handle_option): Don't handle
	OPT_m68000, OPT_mc68000, OPT_m68010, OPT_m68020, OPT_mc68020,
	OPT_m68030, OPT_m68040, OPT_m68060, OPT_m68302, OPT_m68332 and
	OPT_mcpu32.
	* config/m68k/m68k.h (OPTION_DEFAULT_SPECS, ASM_CPU_SPEC): Don't
	handle -mc68000, -m68000, -m68302, -m68010, -mc68020, -m68020,
	-m68030, -m68040, -m68060, -mcpu32 and -m68332.
	* config/m68k/m68k.opt (m68000, m68010, m68020, m68030, m68040,
	m68060, m68302, m68332, mc68000, mc68020, mcpu32): Use Alias.
	* config/m68k/t-mlibs (CANONICALIZE_OPTIONS): Remove.
	(MULTILIB_OPTIONS): Don't use $(CANONICALIZE_OPTIONS).
	(MULTILIB_MATCHES): Map -march= options to corresponding -mcpu=
	options.  Don't map other m68k options manually.  Don't handle
	old-style options as canonical.
	(MULTILIB_EXCEPTIONS): Don't use $(CANONICALIZE_OPTIONS).
	* doc/install.texi (m68k-*-*): Document binutils version
	requirement.

On Wed, Apr 06, 2011 at 10:04:37PM +0000, Joseph S. Myers wrote:
> Similar to <http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00265.html>,
> this patch converts legacy m68k options for non-ColdFire CPUs into
> aliases for the corresponding -mcpu= options.  (Note that -mcpu32 is

While I agree with the CF change, I am sceptical with the m68k case.

> an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old
> code in m68k_handle_option.)  This significantly simplifies the
> multilibs code in t-mlibs, since it no longer needs to handle those
> old-style options (and all cases where two -mcpu= options get the same
> multilib are already handled by the generic logic there rather than
> needing to be listed specially).  The requirement for binutils 2.17 or
> later (to support these options to the assembler) is documented.

I am using m68k-amigos which is not part of the official sources. Since
this target is only about m68k it was no problem to use old(er) binutils
versions. Especially if a target cares only about m68k I would like to
see the legacy m68k options retained.

Regards,
Gunther Nikl

On Thu, 7 Apr 2011, Gunther Nikl wrote:

> > an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old
> > code in m68k_handle_option.)  This significantly simplifies the
> > multilibs code in t-mlibs, since it no longer needs to handle those
> > old-style options (and all cases where two -mcpu= options get the same
> > multilib are already handled by the generic logic there rather than
> > needing to be listed specially).  The requirement for binutils 2.17 or
> > later (to support these options to the assembler) is documented.
> 
> I am using m68k-amigos which is not part of the official sources. Since
> this target is only about m68k it was no problem to use old(er) binutils
> versions. Especially if a target cares only about m68k I would like to
> see the legacy m68k options retained.

I don't see out-of-tree targets as providing a relevant case for blocking 
cleanups, and in any case I think GCC should require a reasonably recent 
binutils (more recent than 2.17) on all targets except where it is 
specifically supporting a "native" system assembler or linker (even there, 
I don't think system assembler support is particularly important except 
where the system tools have features missing from GNU binutils).  The 
legacy options still exist - it's just that they'll be passed to the 
assembler in the canonical -mcpu= form, so you need an assembler 
supporting that form (which any GNU assembler from the past five years 
will do - and I don't think supporting a five-year disparity between GCC 
and binutils versions is productive).

Joseph S. Myers wrote:
> On Thu, 7 Apr 2011, Gunther Nikl wrote:
> 
>>> an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old
>>> code in m68k_handle_option.)  This significantly simplifies the
>>> multilibs code in t-mlibs, since it no longer needs to handle those
>>> old-style options (and all cases where two -mcpu= options get the same
>>> multilib are already handled by the generic logic there rather than
>>> needing to be listed specially).  The requirement for binutils 2.17 or
>>> later (to support these options to the assembler) is documented.
>> I am using m68k-amigos which is not part of the official sources. Since
>> this target is only about m68k it was no problem to use old(er) binutils
>> versions. Especially if a target cares only about m68k I would like to
>> see the legacy m68k options retained.
> 
> I don't see out-of-tree targets as providing a relevant case for blocking 
> cleanups, and in any case I think GCC should require a reasonably recent 
> binutils (more recent than 2.17) on all targets except where it is 

I was under the impression that the used (bin-)utils had to offer
required target support (instructions, directives, object file format)
to be usable with GCC. AFAICT newer binutils versions (in my case
>2.9.1) configured for a m68k-aout style target don't have any relevant
new instructions or directives. Since its only an a.out target on
the assembler level old binutils version used to be sufficient up
to GCC 4.6.
These are SPECs I use for assembler and linker:

#define ASM_CPU_SPEC \
  "%{m68000|mc68000|m68010:-m68010} " \
  "%{m6802*|mc68020:-m68020} " \
  "%{m68030} " \
  "%{m68040} " \
  "%{m68060} " \
  "%{!m680*:%{!mc680*:-m68010}}"

#define LINK_CPU_SPEC \
  "%{m68020|mc68020|m68030:-fl libm020 %{m68881|mhard-float:-fl
libm881}} " \
  "%{m68020-*|m68040|m68060:-fl libm020 %{!msoft-float:-fl libm881}}"

Is with your change really no way to test/pass the original options
to assembler/linker?

> specifically supporting a "native" system assembler or linker (even there, 
> I don't think system assembler support is particularly important except 
> where the system tools have features missing from GNU binutils).  The 
> legacy options still exist - it's just that they'll be passed to the 
> assembler in the canonical -mcpu= form, so you need an assembler 
> supporting that form (which any GNU assembler from the past five years 
> will do - and I don't think supporting a five-year disparity between GCC 
> and binutils versions is productive).

As mentioned above up to GCC 4.6 I am successful using binutils 2.9.1
from 1999. That version offers everything a "simple" m68k a.out target
needs.
Anyway my intention was to offer the view of a m68k target system user.

Regards,
Gunther Nikl

On Tue, 12 Apr 2011, Gunther Nikl wrote:

> I was under the impression that the used (bin-)utils had to offer
> required target support (instructions, directives, object file format)
> to be usable with GCC. AFAICT newer binutils versions (in my case

And command-line options.

> >2.9.1) configured for a m68k-aout style target don't have any relevant
> new instructions or directives. Since its only an a.out target on
> the assembler level old binutils version used to be sufficient up
> to GCC 4.6.

m68k-aout was obsoleted in 4.4 and removed in 4.5 - while some OSes with 
various odd object file formats are still supported, various newer 
features such as LTO may not work so well with them.  Much of the point of 
obsoleting targets no-one wishes to maintain is so that only the remaining 
maintained (and in-tree) targets need to be considered in cleanup patches.

> These are SPECs I use for assembler and linker:
> 
> #define ASM_CPU_SPEC \
>   "%{m68000|mc68000|m68010:-m68010} " \
>   "%{m6802*|mc68020:-m68020} " \
>   "%{m68030} " \
>   "%{m68040} " \
>   "%{m68060} " \
>   "%{!m680*:%{!mc680*:-m68010}}"
> 
> #define LINK_CPU_SPEC \
>   "%{m68020|mc68020|m68030:-fl libm020 %{m68881|mhard-float:-fl
> libm881}} " \
>   "%{m68020-*|m68040|m68060:-fl libm020 %{!msoft-float:-fl libm881}}"
> 
> Is with your change really no way to test/pass the original options
> to assembler/linker?

You could write specs that check for the -mcpu= options and translate them 
back to old-style options acceptable to your assembler and linker.  You 
won't be able to use the generic m68k.h ASM_CPU_SPEC, so all the 
complexity of supporting old assemblers falls on your port, but it should 
be possible - you just can't pass through the options without translating 
them.

Joseph S. Myers wrote:
> 
> m68k-aout was obsoleted in 4.4 and removed in 4.5 - while some OSes
> with various odd object file formats are still supported, various
> newer features such as LTO may not work so well with them.

I am aware that generic m68k-aout as target was deprecated and is gone
now. Apparently that didn't affect my target. I know that eg LTO will
never be available for a.out object files.

>> Is with your change really no way to test/pass the original options
>> to assembler/linker?
> 
> You could write specs that check for the -mcpu= options and translate
> them back to old-style options acceptable to your assembler and linker.

Yes, that would work and the assembler part is easier that I expected.
The following is inspired by something I noticed in the alpha port:

  %{march=*:-m%*} %{mcpu=*:-m%*}

However, the link spec seems to be harder.

  "%{m68020-*|m68040|m68060:-fl libm020}"

Do I have to replace every m680x0 option with a matching mcpu= (maybe
even together with a march=) option?

> You won't be able to use the generic m68k.h ASM_CPU_SPEC, so all the 
> complexity of supporting old assemblers falls on your port, but it should 
> be possible - you just can't pass through the options without translating 
> them.

The port doesn't use the generic ASM_SPECs. AFAIK the port never used
the generic definitions and I kept it that way because I felt more
comfortable using custom definitions.

So problem (almost) solved thanks to the versatile SPEC machinery.

Regards,
Gunther

On Thu, 14 Apr 2011, Gunther Nikl wrote:

> However, the link spec seems to be harder.
> 
>   "%{m68020-*|m68040|m68060:-fl libm020}"
> 
> Do I have to replace every m680x0 option with a matching mcpu= (maybe
> even together with a march=) option?

Whatever options you want to match that spec should be replaced by their 
current versions.  That means m68020-*|mcpu=68040|mcpu=68060 (the 
-m68020-* options haven't been changed into aliases, since they correspond 
to multiple options rather than being equivalent to a single other 
option).