Re: Warning: The structure contains misaligned fields

On Apr 28, 1:39 pm, Craig Powers <eni...@xxxxxxxxxx> wrote:
jamesgi...@xxxxxxx wrote:
...

[The Standard] doesn't usually say anything about memory layout as
such.  However, since SEQUENCE derived types may be used in COMMON
and the components be storage associated through that COMMON with
non-derived-type variables, it's hard to imagine how it would be
implemented without actually being in the order declared.

Depending on what restrictions are imposed on COMMON, it might be
feasible for the compiler to automatically re-order to avoid alignment
issues, as long as that re-ordering were applied consistently across all
contexts.

Yes, as long as the required semantics are accomplished, the standard
otherwise permits implementations to do anything they like. That's
the "as-if" rule. However, as I said, in this case it's difficult to
imagine how to reliably reorder things. Given that COMMON, at the
very least, is likely to involve independently compiled externals, how
does the compiler manage to communicate all the necessary info?
Consider:

type T1
sequence
real :: comp1
double precision :: comp2
integer :: comp3
complex :: comp4
end type
type(t1) :: TVar
complex /aBlock/ Tvar

In another program unit, the COMMON might be declared:

real :: var1
double precision :: var2
integer :: var3
complex :: var4
common /aBlock/ var1, var2, var3, var4

Now these have to interoperate in the obvious way. Each VAR should be
storage associated with the COMP of the same number. Now you might
argue that if the compiler reorders both TYPEs and COMMONs the same
way, what's the problem? But both the above have to interoperate
with:

integer :: ivar(6)
common /aBlock/ ivar

And IVAR(1) in this program unit must be storage associated with VAR1
in the last program unit, IVAR(2) is associated with half of VAR2,
etc. IVAR(4) in this program unit corresponds to VAR3 in the last,
and TVAR%COMP3 in the first program unit. These can interoperate,
since they are also the same type.

But there's even more going on. If I assign a value to IVAR(6) in
this program unit, that causes VAR4 in the last program unit and TVAR
%COMP4 in the first program unit to become undefined. But is doesn't
cause any of the other variables to become undefined. This kind of
pattern applies to all elements of the IVAR array except IVAR(4) -
assigning to any of them causes a corresponding variable in the middle
program unit to become undefined, and also one of the components of
TVAR in the first program unit.

Similar complexities can arise in different ways. Suppose you have a
program unit that defines two derived types: one with a REAL and a
DOUBLE PRECISION component and the other with an INTEGER and a COMPLEX
component. A COMMON with one of each of those types in it should also
interoperate with the original. Additional examples are not hard to
imagine.

Given that the program units might be independently compiled external
procedures, what set of rules for reordering COMMON and/or SEQUENCE
derived types could manage? Certainly having different rules for
reordering if external procedures are present than otherwise would
introduce a good deal of compiler complexity. I suspect you'll not
see SEQUENCE types reordered in actual implementations.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
.

Relevant Pages

  • Re: Same code and different result, Why?
    ... The notion of sequence point is common for all C/C++ compilers. ... This is part for the course for the technology you are using right now, the compiler, including the news groups protocol NNTP you are using, as well as, and especially in Email technology. ... So while we all agreed and acknowledge that this is generally considered an axiom that may produce different results depending on the compiler, when you look at the BCP that exist for the possible results, the MS solution is the least common one. ...
    (microsoft.public.vc.language)
  • Re: Fortran Standard question: COMMON, SAVE and EQUIVALENCE
    ... common in the SAME PROGRAM UNIT. ... *common* statement appends to the ... subroutine sub ...
    (comp.lang.fortran)
  • Re: Fortran Standard question: COMMON, SAVE and EQUIVALENCE
    ... common block to stdout. ... Somehow, with common, equivalence and extensions, I didn't get ... In your case, since you placed blank common in each routine, the first variable in blank common in the routine begins at the beginning of blank common--each is known by a different variable name locally, but the memory association determines that each is really overlaid upon each other in the sequence listed. ... There's really nothing complicated about it; the first variable in each subprogram in a given common block begins at the beginning of the given block and extends as far as it is defined within the program unit. ...
    (comp.lang.fortran)
  • Re: Fortran Standard question: COMMON, SAVE and EQUIVALENCE
    ... implicit integer (h-z) ...   common x ... common in the SAME PROGRAM UNIT. ...
    (comp.lang.fortran)
  • Re: Cohens paper on byte order
    ... > depend on the applicability of the common hex notation. ... bit sequence, there is a bit-order-within-unit issue for ... *any* multibit storage units, not just octet units, and ... fact true of almost all data storage and transmission ...
    (sci.crypt)