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
