In article <199705031930.MAA06300@lestat.nas.nasa.gov> you write:
> 
> ...here's the diff.  The BIGGEST_ALIGNMENT change was the bug fix.

Not being very familar with gcc internals, what does this mean, exactly?
The one line description of BIGGEST_ALIGNMENT isn't very specific.

Is that going to change the meaning of something like:

struct foo {        /* offsets in traditional m6k compilers: */
    char x;         /* bytes 0-0                             */
    short y;        /* bytes 2-3 (byte 1 is padding)         */
    int z;          /* bytes 4-7                             */
}

Yes, this results in slower code than if z was aligned to 32 bits, but
*every* m68k compiler I know of will align to 16 bits by default (except
chars are aligned to 1 byte, of course), and if you want more than that,
insert explicit padding or use compiler directives.  So if we change
this we're going to be incomatible with the rest of the world -- even
other gcc users.  Even old NetBSD objects. 

Here are all the m68k compilers I've either used or linked against code
generated from, all aligned structure members to no more than 16 bits AFAIK:

SunOS/sun32 cc
gcc
Dice C
Lattice C
SAS/C
Manx/Aztec C (but it had 16 bit "int")
Whatever version of Green Hills C on Suns that C= used for Intuition
Sozobon C
AT&T 3b1 C