[m68k 12/13] properly align within code

[Roman Zippel]

Hi,

On Mon, 26 Feb 2007, Jeffrey Law wrote:

> > As I've shown proviously at least the m68k world has shrunk considerably.
> I'm not doubting that.  The question is has the world shrunk enough that
> you can simply remove support for an assembler variant that we have
> supported for 20 years.

A lot of it has already been removed with the removals of many m68k 
targets, e.g.:

http://gcc.gnu.org/viewcvs?view=rev&revision=68962
http://gcc.gnu.org/viewcvs?view=rev&revision=77518

removes explicit assembler support, seriously, there _is_ no other 
explicit support left than for gas. I don't remove anything, that hasn't 
been gone already for at least 3 years...

> One thing you could do that would remove my objection would be to
> show me that there's no way the MOTOROLA_SYNTAX code could possibly
> work in the previous GCC release.  Or that there's no way to actually
> make GCC produce MOTOROLA_SYNTAX in the previous GCC release.
> 
> If that's not possible, then that gives you a direction you can 
> legitimately take.  Disable MOTOROLA_SYNTAX, but keep the code
> working for a release.  When there aren't any complaints after
> a suitable period of time after the next release, then zap all
> MOTOROLA_SYNTAX support.

Huh? I don't want to remove the Motorola syntax.
In this case there's a HAVE_GAS_BALIGN_AND_P2ALIGN I can use.
The other problem are the jump instructions, which don't have anything to 
do with the real Motorola syntax. The "(MOTOROLA)" check doesn't selected 
the Motorola syntax at all.

> > If nobody speaks up in support of other assembler, I don't see any value 
> > in keeping useless code. At the remote chance there is still someone out 
> > there trying to use gcc with an alternative assembler, we likely won't 
> > hear about it until it breaks somehow and if that should happen, I'd 
> > consider it a good thing, so we actually _know_ what kind of support is 
> > needed. OTOH I'd consider it a real bad thing, if this fear of the unknown 
> > kept us of doing some very real and actually useful fixes.
> And the way to get to this state is to disable it, but not otherwise
> break it and wait for a period of time to give the end users a chance
> to complain.

As long as it works nobody will complain...
Do you seriously want to delay _valid_ bug fixes for a release???

bye, Roman