This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

(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:


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
$ find uclinux/lib -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
$ find uclinux/user -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l
find uClibc -name '*.c' -o -name '*.h' | xargs egrep mc68000 | wc -l

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]