This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [m68k] Convert CPP_SPEC to TARGET_CPU_CPP_BUILTINS
On Tue, Sep 16, 2003 at 08:29:47PM +0200, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
>
> >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.
>
> Adding that wouldn't be hard: I just need to allocate a new bit in
> target_flags for MASK_68030, and use that just for the define.
That burns a bit without real need. If mc68030 shall come back I suggest
do add it aagin to CPP_SPEC like this:
"%{m68030:%{!ansi:%{!std=*:-Dmc68030}%{std=gnu*:-Dmc68030}}" \
" -D__mc68030 -D__mc68030__} "
> > [mc68030] was defined there. I just removed it with the 3.3 port when
> > switching to TARGET_CPU_CPP_BUILTINS.
>
> And no one complained about that so far, uh?
Maybe nobody uses my port ;-(
> >> -m68010: define mc68010
> >
> > That doesn't exits.
>
> The same considerations we've done for the __mc68030__ not being useful
> would apply here.
There isn't a -m68010 switch in GCC at all. You don't need to worry about
it.
> >> -m68020-40: define mc68020 mc68030 mc68040
> >> -m68020-60: define mc68020 mc68030 mc68040 mc68060
> >
> > That won't work, would it?
>
> It wouldn't. The first one would just define mc68040, the second would say
> mc68060.
Thats what happens in the AmigaOS port. Before these switches would
define mc68020 on AmigaOS.
> If we really care about it, we could this:
>
> if (TARGET_68040_ONLY)
> {
> if (TARGET_68060)
> define_std("mc68060");
> else
> define_std("mc68040");
> }
> else if (TARGET_68060) /* -m68020-60 */
> {
> define_std("mc68060");
> define_std("mc68040");
> define_std("mc68020");
> }
> else if (TARGET_68040) /* -m68020-40 */
> {
> define_std("mc68040");
> define_std("mc68020");
> }
> else if (TARGET_68020)
> ...
Yes, that seems to be a solution.
> Ouch, that's a problem then, becase TARGET_68881 means
> "I can use any 68881 FP instruction".
There are places where TARGET_68881 is additionally probed against
!TARGET_680[46]0
> If you look at m68k.md, you'll see that GCC already generates some
> FP instructions not supported by the 68060 (fsin, fcos, fsqrt).
I don't know which instructions are not directly supported in HW.
> if TARGET_DEFAULT & MASK_68881:
>
> gcc -m68060
> TARGET_68060: true, TARGET_68881: true, __HAVE_68881__: defined
>
> gcc -m68060 -msoft-float
> TARGET_68060: true, TARGET_68881: false, __HAVE_68881__: undefined
>
> else
>
> gcc -m68060
> TARGET_68060: true, TARGET_68881: true, __HAVE_68881__: undefined
>
> gcc -m68060 -msoft-float
> TARGET_68060: true, TARGET_68881: false, __HAVE_68881__: undefined
>
> gcc -m68060 -m68881
> TARGET_68060: true, TARGET_68881: true, __HAVE_68881__: defined
>
> This doesn't look sane...
Nobody said that it was/is consistent.
Gunther