🚀 go-pugleaf

BACKGROUND:

Two compiler ISSUEs relating to structure padding and alignment have been 
found recently.  The first ISSUE is related to the way that the SUN-target 
compilers pad a structure within a structure with respect to the way it pads 
a union within a structure.  A structure within a structure is padded as if 
the structure does not exist; the alignment rules are followed on a field by 
field basis.  A union within a structure is handled differently: either the 
union is always started on a 32 bit boundary or the largest field is used in 
the alignment rules.  
								 
This difference was brought to light by the fact that one task uses a 
structure within a structure to send messages, while another task uses a 
union within a structure to receive them.  Please note that a problem only 
occurs for SUN-target compilers and does not occurs when the Microtek 
cross-compiler is used with the <-Z2> option (to our knowledge); this is 
only a problem when a Sparc task tries to communicate with another Sparc task.  
The problem was solved by explicitly padding the header to a 32 bit boundary 
for Sparc testing.

The other ISSUE is really the same problem, except that it impacts
a Sparc simulation that drives the target software.  Because headers
are padded to 16 bit rather than 32 bit boundaries for the target, the 
actual data portion of the message can be offset by a word due to the 
reasons that have already been mentioned and due to the difference in
alignment rules.

QUESTION:

Is there an option that pads structures on 16 bit boundaries for the 
Sparc resident GCC compiler?  Such an option would help greatly for
simulations that run from the Sparc.  If you have any ideas, reply through
this venue or send me mail at baumann@comm.mot.com.