Re: [m68k] Convert CPP_SPEC to TARGET_CPU_CPP_BUILTINS

[Gunther Nikl <gni at gecko dot de>]

On Mon, Sep 15, 2003 at 08:58:44PM +0200, Bernardo Innocenti wrote:
> >  It looks like the mc68030 define was added wrongly in the specs.
> 
> Then can we safely drop it? Unless we expect to see much code out there
> that relies on it...

  I have no idea whether code used to test mc68030.

> You've already said that mc68030 is not even being defined on the Amiga,
> so it's safe there too.

  It was defined there. I just removed it with the 3.3 port when switching
  to TARGET_CPU_CPP_BUILTINS.

> >  Whats needed is a way to intercept argument parsing.
> 
> I've already looked into it. Not easy: you can't just hook into
> argument parsing and m68k_override_options gets called too late
> to do something about it.

  Of course, the infrastructure to support that would have to be provided by
  the frontend.

> I'll update the patch to do it the way you suggest.
> It's also closer to the old documentation:
> 
>   -m68000, -mc68000: define nothing else

  Thats always defined.

>   -m68010: define mc68010

  That doesn't exits.

>   -m68020-40: define mc68020 mc68030 mc68040
>   -m68020-60: define mc68020 mc68030 mc68040 mc68060

  That won't work, would it?

> You could still generate 68040 code without 68881. If you say:
> 
>  gcc -m68040 -msoft-float
> 
> The first option will add MASK_68881 to target_flags when parsed,
> the second one will disable it.

  Thats not what I want. GCC did always generate FPU instructions when using
  -m680[46]0. It avoids instructions not present then. HAVE_68881 says its a
  68881/2 which it isn't for the m680[46]0.

> >  Thus HAVE_68881 would now also be defined where it wasn't before. Thats
> >  why I still have it in CPP_SPEC. And I don't want HAVE_68881 be defined
> >  for m680[46]0 because that enables math-68881.h (at least on my system)
> 
> Please note that doing it this way would suck: the compiler would still
> be using FP instructions and registers, but user programs wouldn't be
> able to know.

  It is documented that -m680[46]0 generate FPU instructions!

> I know about the math-68881.h header on the Amiga. IIRC, it replaces
> most transcendental C functions such as sin() with inline FP versions.

  GCC since 3.x install this file in its compiler directory.

> What's the matter with enabling that by defaut when you're already
> generating inline FP code for simple operations such as multiplications?

  These are supported FPU instructions of the m680[46]0. math-68881.h uses
  instruction that have to be emulated and the usage of that file depends
  on HAVE_68881. Maybe not defining HAVE_68881 for m680[46]0 with no FPU
  default was bug. I don't know but I would preserve existing behaviour.

> >  You can by using -m68020 and -mno-bitfield. This would trigger
> >  TARGET_CPU32.
> 
> That's because the only 68020 core without bitfield instructions
> is actually the CPU32 ;-)

  Yes, but before your proposed change CPU32 would only be defined if the
  used really specifify -mcpu32. Now it would also be defined with my
  argument sequence. Is that desirable? I don't think so.

  Gunther