From mboxrd@z Thu Jan 1 00:00:00 1970 From: mrs@wrs.com (Mike Stump) To: wilson@cygnus.com Cc: egcs@cygnus.com Subject: Re: m68k structure packing Date: Tue, 30 Sep 1997 16:58:00 -0000 Message-id: <199709302357.QAA07269@kankakee.wrs.com> X-SW-Source: 1997-09/msg01168.html > Date: Tue, 30 Sep 1997 14:55:51 -0700 > From: Jim Wilson > With this patch, gcc will pack structures regardless of what > STRUCTURE_SIZE_BOUNDARY is set to, but will now in some cases > silently generate code that fails at run time. I would be interested in any such cases that you know of. This cannot happen on the arm, if we are to believe the arm coff or netbsd ports for the arm, as they reset STRUCTURE_SIZE_BOUNDARY to 8. This cannot happen on the sh, if we are to believe the sh ports, as STRUCTURE_SIZE_BOUNDARY defaults to 8. Only with -mpadstruct option does the value change. elxsi doesn't count because it was copied wholesale from the VAX, and I suspect at the time, vax had it as 32, also it doesn't count because I don't think a machine is left in the world that can run. dsp16xx, fx80, mn10200, pyr, spur, tahoe and we32k I cannot comment on, other than to say I think we32k is dead. That leaves m68k. On the m68k the compiler did seem to go out of it's way to generate correct code. Further, Kamil has claimed that the amiga m68k port works fine with STRUCTURE_SIZE_BOUNDARY as 8. Why do you think generated code will fail? Because of unaligned reads and writes? I see many popular machines, and ones that I know have been tested well, that define STRICT_ALIGNMENT and have STRUCTURE_SIZE_BOUNDARY set to 8. Maybe if you describe that case I can hunt for it. If one goes back though the old ChangeLogs, one sees that many ports used to have values other than 8, but over time, they were changed to 8. I think that in the absence a bug that can be reproduced, and since it has been accepted by the FSF for inclusion in the next FSF gcc release, that it be included in egcs. If people that have access to m68000 (not a 030 or a 020) could try out -fpack-struct (with -O, without -O) with my changes, and try and make it fail, that would be a big help in ensuring that no bug is introduced. It is probably imporant that the code run on a m68k that requires alignment (if I understand Jim's concerns).