Re: [Fwd: [m68k] Remove duplicate mc68000 predefine.]

[Bernardo Innocenti <bernie at develer dot com>]

(gcc-patches back on Cc to see what the other GCC developers
think about it).


Ralf Corsepius wrote:
> On Mon, 2004-12-13 at 17:54 +0100, Bernardo Innocenti wrote:
>
> > Ralf Corsepius wrote:
> >
> > > Chris,
> > >
> > > What do you think about this proposal?
> > >
> > > IMO, Bernardo's patch is heading into the correct direction as it is
> > > trying to clean up the "predefine-mess" for the m68k, so I am inclined
> > > to agree to his proposal.
> > >
> > > However, a grep through RTEMS and newlib's sources reveals several spots
> > > relying on __mc68000__ or mc68000 being defined, both in RTEMS and
> > > newlib, which each would require to be looked after.
> >
> > We would *still* have the __mc68000__ predefine (*),
> > because there's another copy in m68k.h :-)
>
> :/)
>
>
> > (*) along with the non-ANSI __mc68000 and m68000 variants.
> >
> > I'd like to remove it altogether and only enable it
> > for code compiled with -m68000, but that would break
> > lots of existing code.
>
> I had assumed as much :-)
>
> IMO, it would be the next logical/natural step. Furthermore a major
> release such as gcc-4.0 seems to be a suitable point for such an step.


I do agree with you, but we're in stage 3 and it's way too late
to get something like this approved.

Besides, I've made some quick research:

$ find linux-2.6.x-cvs -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
52
$ find uclinux/lib -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
20
$ find uclinux/user -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
11
find uClibc -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
6


I could submit patches to fix most of uClinux, uClibc and the Linux kernel,
but developers may want to use GCC 4.0 with old versions.

Embedded developers are expecially conservative and are going
to complain loudly for breaking compatibility.

Moreover, a stray #ifdef __mc68000__ left in the code would subtly
break existing applications.  If you're lucky, it would just be
a performance problem.

Is there a way to emit a warning in the preprocessor for using
an obsolete symbol?  This way we could declare __mc68000__ obsolete
in 4.0 and remove it altogether in another 3-5 years.


> > For RTEMS, I'd suggest testing for __m68k__ instead
> > of __mc68000__, in case we finally get to drop this
> > compatibility hack in the long term.
>
> We already are using this at many places (Unfortunately, seemingly not
> at all places), but apparently newlib doesn't.

The only places where newlib seems to care about m68k
are setjmp.h and ieeefp.h.  The former still uses __mc68000__,
the latter uses both, maybe just in case :-)

I've checked and it seems __m68k__ was already present in
gcc 2.95.2, at least for some targets.  Each particular target
had a local copy of the CPU predefines in CPP_SPECS back then.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/