Cleanups for the m68k backend

[Franz Sirl]

At 15:41 07.07.2003, Gunther Nikl wrote:
>On Mon, Jul 07, 2003 at 03:23:18PM +0200, Franz Sirl wrote:
> > At 15:01 07.07.2003, Gunther Nikl wrote:
> > >On Mon, Jul 07, 2003 at 02:50:06PM +0200, Bernardo Innocenti wrote:
> > >> On Monday 07 July 2003 13:14, Gunther Nikl wrote:
> > >>
> > >>  > On Mon, Jul 07, 2003 at 11:24:43AM +0200, Andreas Schwab wrote:
> > >>  > > Note that GAS accepts both syntaxes, so if every supported 
> target is
> > >>  > > using GAS then we can rip it out immediately.
> > >>  >
> > >>  >   Not every GAS version supports it. Why removing MIT syntax? The 
> same
> > >>  > could be demanded for Motorola syntax...
> > >>
> > >>  Maintaing both syntaxes adds complexity
> > >
> > >  Yes, but not that much.
> > >
> > >> and makes every change to the m68k back-end harder to write and test.
> > >
> > >  No. If you don't like the #idefs then make MOTOROLA a 0/1 define and use
> > >  real if()s.
> >
> > No, that's not how it works with open source. If _you_ want to keep a
> > rarely necessary feature that makes maintenance a nightmare (see grep
> > "#.*include" gcc/config/m68k/*.h|wc -l), it's _your_ task to spend some
> > time on it (namely convert #include's to $tm_file in config.gcc).
>
>   Thats an entirely different issue, isn't it?

Not really, as I understand Bernardo he will be doing more cleanups in the 
future and if that's the case I would rather pave him the way than to keep 
some feature.


> > And note that this isn't just an isolated m68k issue, everyone doing
> > compilerwide cleanups usually stumbles over m68k :-(.
>
>   Because its still an CC target or why?

Because due to the strange #include setup it's hard to prove that you 
didn't break some strange configuration. Eg., when I moved the elfos.h 
includes to $tm_file m68k was one of the worst platforms to handle, 
conditional includes, #define/#include/#undef sequences, etc.

Franz.