Re: Convert legacy m68k options to .opt aliases
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).
--
Joseph S. Myers
jos...@codesourcery.com
Re: Convert legacy m68k options to .opt aliases
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
Re: Convert legacy m68k options to .opt aliases
On Wed, Apr 06, 2011 at 10:04:37PM +, 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
Re: Convert legacy m68k options to .opt aliases
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 jos...@codesourcery.com
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 jos...@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.
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 \
- ? mMLIB=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:
