#pragma push breaks bootstrap?

[Robert Lipe]

Hi, Nick.

Thanx for the quick reply.   Comments blow.

> : In this example, "stage1/" holds a "bad" compiler and "stage2/" holds
> : one that works.  As a sanity check, I show the results from the system
> : 
> : 
> : (robertl) rjlhome:/play/negcs/gcc
> : $ stage1/xgcc -Bstage1/ /tmp/p.c && ./a.out
> : 10 18
> : 18
> : (robertl) rjlhome:/play/negcs/gcc
> : $ stage2/xgcc -Bstage2/ /tmp/p.c && ./a.out
> : 10 10
> : 10
> : (robertl) rjlhome:/play/negcs/gcc
> : $ /bin/cc /tmp/p.c && ./a.out
> : 10 10
> : 10

[ Note to the reader, these numbers are in hex, not decimal ] 

> Is stage1/xgcc the one built when HANDLE_PRAGMA_PACK_PUSH_POP is
> enabled or disabled ?

Stage1/xgcc has it enabled.   It's the one that disagrees with the
native tools about the size of the structure in question.

> You see with the new code defining either (or both of)
> HANDLE_SYSV_PRAGMA or HANDLE_PRAGMA_PACK_PUSH_POP in a target header
> file will cause HANDLE_PRAGMA_PACK to be defined in c-pragma.h, which
> will enable the parsing of #pragma pack(<n>) in c-pragma.c.  So even

Yes, now that I have things locked in the debugger, that's exactly
what I'm seeing.   Watchpoints on maximum_field_alignment show it
toggling in the same way at the same time with or without H_P_P_P_P
so that doesn't seem to be the issue.

> if HANDLE_PRAGMA_PACK_PUSH_POP is *not* defined but HANDLE_SYSV_PRAGMA
> *is* defined then the (rearranged) code for handling #pragma pack(<n>)
> should be used.  And since gcc appears to work when H_P_P_P_P is not

Yes.  I can see the same code is indeed used for parsing both cases.  I
see that in the testcases, push_alignment is never called.   So I don't
think that it's falsely confusing the two variants.

> defined, it would appear that the code is working....  

For whatever reason that we haven't found yet, egcs with H_P_P_P_P
enabled and every other compiler I have ready access to on OpenServer
are disagreeing about the size of this structure.  (Four compilers by
three distinctly different vendors not counting other GCC derivitaves.)
The default alignment is documented as '4' on the ones from Intel, SCO,
and Microsoft.  I can't find a documented default for EGCS.

The difference seems to be that they disagree about how to handle the
following case:

#pragma pack(4)
struct blah { char a1; char a2; char a3};

Compiler balloting (yes, i understand the danger of that :-) says that
sizeof (struct blah) == 3.  Without H_P_P_P_P, egcs says that the
size is 3.  With H_P_P_P_P_P, egcs says the size is 12.  If we remove
the 'pragma pack' line (which doesn't make a difference on the others
becuase that's already the documented default) H_P_P_P_P_P agrees with
the others.

Unfortunately, I don't understand enough about trees to trace into
the guts of insert_pack_attributes() and debug it in any meaningful
way.

> [All of this assumes that HANDLE_SYSV_PRAGMA is defined in your
> toiolchain.  Could you just check this to make sure].

config/i386/sco5.h definitely sets HANDLE_SYSV_PRAGMA.   This has been
working fine in the OpenServer port until very recently.

Before we chase this a lot further, can I ask a silly question?  Since
insert_pack_attributes() has a non-zero cost (breakpoints show it being
called many times for even the simple example) and presumably provides
benefits only to those that need the Windows-ism 'pragma push' should
we move the setting of this out of i386.h and into the target-specific
files for those targets that care about that extension? (winnt.h,
go32.h, cygwin32, mingw, etc.)

Thanx for any guidance you can offer and the help so far.
RJL