Patchwork Convert legacy m68k options to .opt aliases

login
register
mail settings
Submitter Joseph S. Myers
Date April 6, 2011, 10:04 p.m.
Message ID <Pine.LNX.4.64.1104062204130.19324@digraph.polyomino.org.uk>
Download mbox | patch
Permalink /patch/90096/
State New
Headers show

Comments

Joseph S. Myers - April 6, 2011, 10:04 p.m.
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.
Gunther Nikl - April 7, 2011, 3:01 p.m.
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
Joseph S. Myers - April 7, 2011, 4:36 p.m.
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).
Gunther Nikl - April 12, 2011, 6:10 p.m.
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
Joseph S. Myers - April 12, 2011, 8:33 p.m.
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.
Gunther Nikl - April 14, 2011, 6:18 p.m.
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
Joseph S. Myers - April 21, 2011, 4:34 p.m.
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).

Patch

Index: gcc/doc/install.texi
===================================================================
--- gcc/doc/install.texi	(revision 172035)
+++ gcc/doc/install.texi	(working copy)
@@ -3773,6 +3773,8 @@  be a @option{-mcpu} argument or one of t
 @samp{m68000}, @samp{m68010}, @samp{m68020}, @samp{m68030},
 @samp{m68040}, @samp{m68060}, @samp{m68020-40} and @samp{m68020-60}.
 
+GCC requires at least binutils version 2.17 on these targets.
+
 @html
 <hr />
 @end html
Index: gcc/config/m68k/t-mlibs
===================================================================
--- gcc/config/m68k/t-mlibs	(revision 172035)
+++ gcc/config/m68k/t-mlibs	(working copy)
@@ -45,15 +45,9 @@  ifeq ($(filter m$(M68K_MLIB_DEFAULT),$(M
 $(error Error default cpu '$(target_cpu_default)' is not in multilib set '$(M68K_MLIB_CPUS)')
 endif
 
-# Sed arguments that convert mcpu=* arguments into canonical forms.
-# We want to use the legacy m68* options instead of the new -mcpu=68*
-# options when compiling multilibs because the former are recognised
-# by older binutils.
-CANONICALIZE_OPTIONS = -e 's|mcpu=68|m68|g' -e 's|mcpu=cpu32|mcpu32|g'
-
 MULTILIB_DIRNAMES := $(filter-out m$(M68K_MLIB_DEFAULT),$(M68K_MLIB_CPUS))
 MULTILIB_OPTIONS := $(shell echo $(MULTILIB_DIRNAMES:m%=mcpu=%) \
-		      | sed -e 's| |/|g' $(CANONICALIZE_OPTIONS))
+		      | sed -e 's| |/|g' )
 
 # Add subtarget specific options & dirs.
 MULTILIB_DIRNAMES += $(M68K_MLIB_DIRNAMES)
@@ -62,14 +56,13 @@  MULTILIB_OPTIONS += $(M68K_MLIB_OPTIONS)
 MULTILIB_MATCHES :=
 
 ifneq ($(M68K_ARCH),cf)
-# Map the new-style options to the legacy m68k ones.
-MULTILIB_MATCHES += m68000=mcpu?68000 m68000=march?68000 m68000=mc68000 \
-		    m68000=m68302 \
-		    m68020=mcpu?68020 m68020=march?68020 m68020=mc68020 \
-		    m68030=mcpu?68030 m68030=march?68030 \
-		    m68040=mcpu?68040 m68040=march?68040 \
-		    m68060=mcpu?68060 m68060=march?68060 \
-		    mcpu32=mcpu?cpu32 mcpu32=march?cpu32 mcpu32=m68332
+# Map -march=* options to the representative -mcpu=* option.
+MULTILIB_MATCHES += mcpu?68000=march?68000 \
+		    mcpu?68020=march?68020 \
+		    mcpu?68030=march?68030 \
+		    mcpu?68040=march?68040 \
+		    mcpu?68060=march?68060 \
+		    mcpu?cpu32=march?cpu32
 endif
 
 ifneq ($(M68K_ARCH),m68k)
@@ -82,9 +75,7 @@  endif
 MULTILIB_MATCHES += \
   $(call M68K_AWK, \
 	 (CPU_NAME != MLIB) $(M68K_MLIB_CPU), \
-	 (match(MLIB, "^68") || MLIB == "cpu32" \
-	  ? "m"MLIB"=mcpu?"CPU_NAME \
-	  : "mcpu?"MLIB"=mcpu?"CPU_NAME))
+	 ("mcpu?"MLIB"=mcpu?"CPU_NAME))
 
 MULTILIB_EXCEPTIONS :=
 
@@ -102,9 +93,5 @@  endif
 MULTILIB_EXCEPTIONS := \
 	$(patsubst mcpu=$(M68K_MLIB_DEFAULT)/%,%,$(MULTILIB_EXCEPTIONS))
 
-# Convert all options to canonical form.
-MULTILIB_EXCEPTIONS := $(shell echo $(MULTILIB_EXCEPTIONS) | \
-			 sed $(CANONICALIZE_OPTIONS))
-
 LIBGCC = stmp-multilib
 INSTALL_LIBGCC = install-multilib
Index: gcc/config/m68k/m68k.opt
===================================================================
--- gcc/config/m68k/m68k.opt	(revision 172035)
+++ gcc/config/m68k/m68k.opt	(working copy)
@@ -40,15 +40,15 @@  Target RejectNegative Alias(mcpu=, 5407)
 Generate code for a 5407
 
 m68000
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68000)
 Generate code for a 68000
 
 m68010
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68010)
 Generate code for a 68010
 
 m68020
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68020)
 Generate code for a 68020
 
 m68020-40
@@ -60,23 +60,23 @@  Target RejectNegative
 Generate code for a 68060, without any new instructions
 
 m68030
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68030)
 Generate code for a 68030
 
 m68040
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68040)
 Generate code for a 68040
 
 m68060
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68060)
 Generate code for a 68060
 
 m68302
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68302)
 Generate code for a 68302
 
 m68332
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68332)
 Generate code for a 68332
 
 ; Has no effect on gcc
@@ -101,11 +101,11 @@  Target Report Mask(BITFIELD)
 Use the bit-field instructions
 
 mc68000
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68000)
 Generate code for a 68000
 
 mc68020
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68020)
 Generate code for a 68020
 
 mcfv4e
@@ -117,7 +117,7 @@  Target RejectNegative Joined
 Specify the target CPU
 
 mcpu32
-Target RejectNegative
+Target RejectNegative Alias(mcpu=, 68332)
 Generate code for a cpu32
 
 mdiv
Index: gcc/config/m68k/m68k.c
===================================================================
--- gcc/config/m68k/m68k.c	(revision 172035)
+++ gcc/config/m68k/m68k.c	(working copy)
@@ -499,17 +499,6 @@  m68k_handle_option (struct gcc_options *
     case OPT_mtune_:
       return m68k_find_selection (&m68k_tune_entry, all_microarchs, arg);
 
-    case OPT_m68000:
-    case OPT_mc68000:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68000");
-
-    case OPT_m68010:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68010");
-
-    case OPT_m68020:
-    case OPT_mc68020:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68020");
-
     case OPT_m68020_40:
       return (m68k_find_selection (&m68k_tune_entry, all_microarchs,
 				   "68020-40")
@@ -520,22 +509,6 @@  m68k_handle_option (struct gcc_options *
 				   "68020-60")
 	      && m68k_find_selection (&m68k_cpu_entry, all_devices, "68020"));
 
-    case OPT_m68030:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68030");
-
-    case OPT_m68040:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68040");
-
-    case OPT_m68060:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68060");
-
-    case OPT_m68302:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68302");
-
-    case OPT_m68332:
-    case OPT_mcpu32:
-      return m68k_find_selection (&m68k_cpu_entry, all_devices, "68332");
-
     case OPT_mshared_library_id_:
       if (value > MAX_LIBRARY_ID)
 	error ("-mshared-library-id=%s is not between 0 and %d",
Index: gcc/config/m68k/m68k.h
===================================================================
--- gcc/config/m68k/m68k.h	(revision 172035)
+++ gcc/config/m68k/m68k.h	(working copy)
@@ -30,9 +30,8 @@  along with GCC; see the file COPYING3.  
 
 /* Handle --with-cpu default option from configure script.  */
 #define OPTION_DEFAULT_SPECS						\
-  { "cpu",   "%{!mc68000:%{!m68000:%{!m68302:%{!m68010:%{!mc68020:%{!m68020:\
-%{!m68030:%{!m68040:%{!m68020-40:%{!m68020-60:%{!m68060:%{!mcpu32:%{!m68332:\
-%{!mcpu=*:%{!march=*:-%(VALUE)}}}}}}}}}}}}}}}" },
+  { "cpu",   "%{!m68020-40:%{!m68020-60:\
+%{!mcpu=*:%{!march=*:-%(VALUE)}}}}" },
 
 /* Pass flags to gas indicating which type of processor we have.  This
    can be simplified when we can rely on the assembler supporting .cpu
@@ -40,9 +39,7 @@  along with GCC; see the file COPYING3.  
 
 #define ASM_CPU_SPEC "\
 %{m68851}%{mno-68851} %{m68881}%{mno-68881} %{msoft-float:-mno-float} \
-%{m68000}%{m68302}%{mc68000}%{m68010}%{m68020}%{mc68020}%{m68030}\
-%{m68040}%{m68020-40:-m68040}%{m68020-60:-m68040}\
-%{m68060}%{mcpu32}%{m68332}\
+%{m68020-40:-m68040}%{m68020-60:-m68040}\
 %{mcpu=*:-mcpu=%*}%{march=*:-march=%*}\
 "
 #define ASM_PCREL_SPEC "%{fPIC|fpic|mpcrel:--pcrel} \