(patch) pragma pack lossage

[Jeffrey A Law]

  In message < 199907011826.NAA19012@mercury.xraylith.wisc.edu >you write:
  > If you read through my posting (I know it's verbose, but I wanted to get
  > all the relevant info in there for future reference),
Err, I read it when you sent it (twice), I re-read it again and I still do not
see what point you're trying to make in that message.

  > the current code for
  > PRAGMA_INSERT_ATTRIBUTES is *never* executed for #pragma pack(<n>), which
  > is eg., heavily used by RJL's ports. It doesn't seem intentional to be 
  > this way, and only happened due to the way the code is structured. 
This, as far as I can tell is a complete side issue.  Your original
message complained that insert_pack_attributes did the wrong thing and that
it should be deleted.  My contention is we should fix insert_pack_attributes.

If we need to fix the pack <n> support so that it calls a properly functioning
insert_pack_attributes, then we should do that too.  The fact that the 
#pragma pack <n> is not calling insert_pack_attributes is not (as far as
I can tell) a reason to delete the call to insert_pack_attributes.


  > GCC's backend uses 'maximum_field_alignment' to align and lay out the 
  > various fields, and that's sufficient to be compatible with pragma 
  > packing semantics. Given a non-zero value of maximum_field_alignment,
  > #pragma pack(<n>) is not equivalent to any combination GCC's packed 
  > and aligned attributes (it screws up bitfield packing in a big way). 
  > That's why the code is incorrect and should be removed. It wasn't 
  > there before, and it shouldn't be there in the future. layout_record
  > in stor-layout.c knows better, and we should let it do its job.
This I understand.  I'm not sure if I agree with the assertion that it is
not equivalent, but that may simply be because I'm not familiar with this
code.


  > When you get some time (yeah, right ;-), please read through the logic
  > of how #pragma pack(<n>) is handled and how #pragma pack(push, <n>)
  > is handled.
How about instead you discuss it with the original author who presumably
knows the code better than I am likely to know it even after studying the
code for a few hours.  (Nick Clifton).


jeff