From: mrs@wrs.com (Mike Stump)
To: mycroft@mit.edu
Cc: egcs@cygnus.com
Subject: Re: m68k structure packing
Date: Tue, 30 Sep 1997 13:32:00 -0000 [thread overview]
Message-ID: <199709302029.NAA01776@kankakee.wrs.com> (raw)
> 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))?
next reply other threads:[~1997-09-30 13:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-09-30 13:32 Mike Stump [this message]
1997-09-30 14:56 ` Jim Wilson
-- strict thread matches above, loose matches on Subject: below --
1997-10-01 15:08 Mike Stump
1997-10-01 15:56 ` Peter Barada
1997-10-01 16:16 ` Per Bothner
1997-10-02 20:14 ` Jim Wilson
1997-10-02 6:49 ` Paul Koning
1997-10-02 20:09 ` Jim Wilson
1997-10-02 20:01 ` Jim Wilson
1997-10-02 21:40 ` Richard Henderson
1997-10-01 12:16 Mike Stump
1997-10-01 12:39 ` Joel Sherrill
1997-10-02 18:37 ` Jim Wilson
1997-09-30 21:42 Jim Wilson
1997-10-01 5:44 ` Kamil Iskra
1997-09-30 20:16 Mike Stump
1997-09-30 22:03 ` Jeffrey A Law
1997-09-30 16:58 Mike Stump
1997-09-30 18:20 ` Jim Wilson
1997-10-01 9:02 ` Peter Barada
1997-09-30 12:08 Mike Stump
1997-09-30 12:57 ` Charles M. Hannum
1997-09-30 19:58 ` Jim Wilson
1997-09-30 21:13 ` Richard Henderson
1997-09-30 21:22 ` Jim Wilson
1997-10-01 15:14 ` Jim Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199709302029.NAA01776@kankakee.wrs.com \
--to=mrs@wrs.com \
--cc=egcs@cygnus.com \
--cc=mycroft@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).