m68k structure packing

Mike Stump mrs@wrs.com
Tue Sep 30 13:32:00 GMT 1997


> To: mrs@wrs.com (Mike Stump)
> From: mycroft@mit.edu (Charles M. Hannum)
> Date: 30 Sep 1997 16:01:24 -0400

> Um, doesn't this *severely* break compatibility?

I guess it depends upon how you use the words and what they mean to
you.  Yes, this work causes the compiler to not have a bug that it had
before, and lack of that bug makes some objects not binary compatible
with prior objects on some systems.  For completeness the systems are:

config/arm/arm.h:#define STRUCTURE_SIZE_BOUNDARY 32
config/dsp16xx/dsp16xx.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/elxsi/elxsi.h:#define STRUCTURE_SIZE_BOUNDARY 32
config/fx80/fx80.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/3b1g.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/a-ux.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/altos3068.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/apollo68.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/ccur-GAS.h:#define STRUCTURE_SIZE_BOUNDARY 16 
config/m68k/crds.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/hp2bsd.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/hp320.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/hp3bsd.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/hp3bsd44.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/isi.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/lynx-ng.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/lynx.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/mot3300.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/netbsd.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/next.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/pbb.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/plexus.h:#define STRUCTURE_SIZE_BOUNDARY 16 /* for compatibility with cc */
config/m68k/sun2.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/sun3.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/tower.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/m68k/vxm68k.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/mn10200/mn10200.h:#define STRUCTURE_SIZE_BOUNDARY 16
config/pyr/pyr.h:#define STRUCTURE_SIZE_BOUNDARY 32
config/sh/sh.h:#define STRUCTURE_SIZE_BOUNDARY (TARGET_PADSTRUCT ? 32 : 8)
config/spur/spur.h:#define STRUCTURE_SIZE_BOUNDARY 32
config/tahoe/tahoe.h:#define STRUCTURE_SIZE_BOUNDARY 32
config/we32k/we32k.h:#define STRUCTURE_SIZE_BOUNDARY 32

Note that only code that specifies -fpack-struct, or attribute
((packed)) on only the above systems is broken by the change, code
that does not, cannot be broken.  The code that specifies either of
these two mechanisms, is now more compatible across platforms
(desirable), where as before, the compiler would just do the wrong
thing on some platforms.  I think the consistency across platforms,
and providing a way for a programmer to customize structure layout to
his liking is more important than allowing this bug to continue to
live.  Be aware, that the people using -fpack-struct or attribute
((packed)) are exactly the people that would want this problem fixed,
so to them, they can tolerate the incompatibility.

Do you use -fpack-struct or attribute ((packed))?



More information about the Gcc mailing list