Studying note of GCC-3.4.6 source (15)

2.2.3.1.5.2.2.6. FIELD_DECL of RECORD_TYPE
We have known thatFIELD_DECL is used to represent a non-static data member, and the detail is given in following
FIELD_DECL[2]
² These nodes represent non-static data members. The DECL_SIZE and DECL_ALIGN behave as for VAR_DECL nodes. The DECL_FIELD_BITPOS gives the first bit used for this field, as an INTEGER_CST. These values are indexed from zero, where zero indicates the first bit in the object.
If DECL_C_BIT_FIELD holds, this field is a bit-field.
2.2.3.1.5.2.2.6.1. Find Out Alignment of FIELD_DECL
Similarly fields in RECORD_TYPE (class or struct) are laid out by place_field. It worthes pointing out that, this function is not only invoked by layout_type, to do layout for compiler declaring structure; but also by layout_class_type to lay out user defined structure.
Alignment of field will affect the layout of structure greatly. On some machine, majorly RISC one, unaligned data will crash the machine. On other machines, though no crash incurred, the effciency is badly impacted. So unless explicitly pointed out, the compiler will generate code with data aligned. Of course, it is not for free. Code with data aligned is bigger than that with packed data. It will occupy more disk space and memory. Sometimes to ensure the data has the same size on all target platforms, or to force the data into a limit vacancy, it needs specify the alignment for the data or make it packed. In code of Linux kernel and drivers, such examples can be found. To control the layout of data, GCC provides attributes, such as: packed, align; directive, like: #pragma pack(N); and switch as: ms-bitfields/noms-bitfields.
And what makes the fields’ layout more complex is the bit field. MS layout permit adjacent same type bit fields to share the same memory unit as long as the total size is not overflow. While in GCC default layout, bit fields of different types still can share same memory unit. An important variation of bit field is the zero size bit field. For such declarations, they must be nameless. In short, zero size bit field inserted among other bit fields will cause bit field following being placed at boundary of its alignment no matter how many bits left in previous memory unit. And tailing zero size bit field will be ignored.
Following code snippet of place_field lays out fields as mentioned above.

place_field (continue)

860 /* Work out the known alignment so far. Note that A & (-A) is the
861 value of the least-significant bit in A that is one. */
862 if (!integer_zerop (rli->bitpos))
863 known_align = (tree_low_cst (rli->bitpos, 1)
864 & - tree_low_cst (rli->bitpos, 1));
865 else if (integer_zerop (rli->offset))
866 known_align = BIGGEST_ALIGNMENT;
867 else if (host_integerp (rli->offset, 1))
868 known_align = (BITS_PER_UNIT
869 * (tree_low_cst (rli->offset, 1)
870 & - tree_low_cst (rli->offset, 1)));
871 else
872 known_align = rli->offset_align;
873
874 desired_align = update_alignment_for_field (rli, field, known_align);

bitpos in record_layout_info holds current bit position. It is countered after offset. While offset records bytes of the part laid out, not including bits in bitpos. Later we will see that.
So beginning at line 862, if small type has followed large type as above example (condition at line 862), known_align is set as the nonzero least significant bit in bitpos. Then if it is first to layout the record (offset is size_zero_node, condition at line 865), known_align is set as BIGGEST_ALIGNMENT in the platform (128 bits for x86, that means for x86 system); otherwise, if offset can be processed efficiently (integer constant less than 4G), known_align is set with nonzero least significant bit in offset multiplied with BITS_PER_UNIT. When satisfies condition at line 871, it means seen field of non-constant size (for C++, it almost indicates a wrong declaration, and later we can see that for declaration of template, it will be laid out only at point of instantiation), thus known_align can’t be determined via the part laid out, just only assumes it the same as offset_align.
We have seen update_alignment_for_field above, it will return the final alignment (in bits) for the field. Remember here, as we find out in 2.2.3.3.1.5.3.5.2 Treatment for Bit Field Decl, for non-zero size bit field, if it is not replaced by certain integer mode in layout_decl, its DECL_ALIGN will be zero.
2.2.3.1.5.2.2.6.2. Alignment – unneccessary packing
If using switch –Wpacked, warn_packed below will be set as nonzero. In case of the packed attribute is uneccessary and inefficient, gives out warning. And nonzero DECL_PACKED indicates the field is bit packed (that is packed attribure in used).

place_field (continue)

876 if (warn_packed && DECL_PACKED (field))
877 {
878 if (known_align >= TYPE_ALIGN (type))
879 {
880 if (TYPE_ALIGN (type) > desired_align)
881 {
882 if (STRICT_ALIGNMENT)
883 warning ("%Jpacked attribute causes inefficient alignment "
884 "for '%D'", field, field);
885 else
886 warning ("%Jpacked attribute is unnecessary for '%D'",
887 field, field);
888 }
889 }
890 else
891 rli->packed_maybe_necessary = 1;
892 }

Now know_align basically is the alignment of the last bit of the previous field (note that the next bit is unoccupied), and desired_align is the expected alignment for the field. No doubt if known_align is larger than desired_align, the field can be placed from the next bit naturally even without packed attribute. For this unneccessary packed attribute, the compiler may generate inefficient code. For example, STRICT_ALIGNMENT at line 882 is set as 1 for platform on which move instruction will fail to work when given unaligned data. The compiler will avoid generating such code on those platforms, though doing that is unneccessary for the case.
2.2.3.1.5.2.2.6.3. Alignment – padding required
If desired_align larger than known_align, then there is gap between fields, it requires padding to round the next field to desired boundary. Below warn_padded is set by switch –Wpadded, if set, it will give out warning for padding.

place_field (continue)

894 /* Does this field automatically have alignment it needs by virtue
895 of the fields that precede it and the record's own alignment? */
896 if (known_align < desired_align)
897 {
898 /* No, we need to skip space before this field.
899 Bump the cumulative size to multiple of field alignment. */
900
901 if (warn_padded)
902 warning ("%Jpadding struct to align '%D'", field, field);
903
904 /* If the alignment is still within offset_align, just align
905 the bit position. */
906 if (desired_align < rli->offset_align)
907 rli->bitpos = round_up (rli->bitpos, desired_align);
908 else
909 {
910 /* First adjust OFFSET by the partial bits, then align. */
911 rli->offset
912 = size_binop (PLUS_EXPR, rli->offset,
913 convert (sizetype,
914 size_binop (CEIL_DIV_EXPR, rli->bitpos,
915 bitsize_unit_node)));
916 rli->bitpos = bitsize_zero_node;
917
918 rli->offset = round_up (rli->offset, desired_align / BITS_PER_UNIT);
919 }
920
921 if (! TREE_CONSTANT (rli->offset))
922 rli->offset_align = desired_align;
923
924 }

When desired_align larger than known_algin, but less than offset_align, for example, the f2 in below declaration:
struct temp {
int f1:17; // known_align: 15, offset_align: 128, bitpos: 17
short f2:10; // desired_align: 16
};
In the case, if it is GCC default layout, f1 and f2 can share the same memory of size int. Since bitpos records the bits not cross the alignment boundary and still not submitted, even includes the field, it may still within the boundary, thus bitpos is round to the boundary of desired_align (later we can see that for bit-field under MS layout, this adjustment will be ignored).
Then if desired_align larger than offset_align, which means we are within a layout of nonconstant size (in layout having all field of constant size, offset_align will keep 128 the biggest possible alignment). For the case offset_align records the alignment of the part laid out. Then condition at line 921 will be satisfied too, so offset_align keeps track of the alignment.
2.2.3.1.5.2.2.6.4. Alignment – bit field in GCC layout
As we have seen, on machine without bit-field operating instructions, at line 829, PCC_BITFIELD_TYPE_MATTERS must be defined as 1, so as to avoid bit-field cross alignment boundary (x86 is such machine). Though in GCC default layout, bit-fields of types of different size can share the same memory unit, with PCC_BITFIELD_TYPE_MATTERS of 1, it must ensure that no bit-field will break out.

place_field (continue)

926 /* Handle compatibility with PCC. Note that if the record has any
927 variable-sized fields, we need not worry about compatibility. */
928 #ifdef PCC_BITFIELD_TYPE_MATTERS
929 if (PCC_BITFIELD_TYPE_MATTERS
930 && ! (* targetm.ms_bitfield_layout_p) (rli->t)
931 && TREE_CODE (field) == FIELD_DECL
932 && type != error_mark_node
933 && DECL_BIT_FIELD (field)
934 && ! DECL_PACKED (field)
935 && maximum_field_alignment == 0
936 && ! integer_zerop (DECL_SIZE (field))
937 && host_integerp (DECL_SIZE (field), 1)
938 && host_integerp (rli->offset, 1)
939 && host_integerp (TYPE_SIZE (type), 1))
940 {
941 unsigned int type_align = TYPE_ALIGN (type);
942 tree dsize = DECL_SIZE (field);
943 HOST_WIDE_INT field_size = tree_low_cst (dsize, 1);
944 HOST_WIDE_INT offset = tree_low_cst (rli->offset, 0);
945 HOST_WIDE_INT bit_offset = tree_low_cst (rli->bitpos, 0);
946
947 #ifdef ADJUST_FIELD_ALIGN
948 if (! TYPE_USER_ALIGN (type))
949 type_align = ADJUST_FIELD_ALIGN (field, type_align);
950 #endif
951
952 /* A bit field may not span more units of alignment of its type
953 than its type itself. Advance to next boundary if necessary. */
954 if (excess_unit_span (offset, bit_offset, field_size, type_align, type))
955 rli->bitpos = round_up (rli->bitpos, type_align);
956
957 TYPE_USER_ALIGN (rli->t) |= TYPE_USER_ALIGN (type);
958 }
959 #endif
960
961 #ifdef BITFIELD_NBYTES_LIMITED
…
998 #endif

As seeing in section about in layout of union, macro ADJUST_FIELD_ALIGN invokes x86_field_alignment to adjust the type alignment according to the requirement upon the platform. If bit field crosses the alignment boundary of its type, bitpos will be updated to the boundary of type alignment – that means place the bit field in new memory unit.
excess_unit_span is used to find out the situation of crossing boundary.

801 static int
802 excess_unit_span (HOST_WIDE_INT byte_offset, HOST_WIDE_INT bit_offset, in stor-layout.c
803 HOST_WIDE_INT size, HOST_WIDE_INT align, tree type)
804 {
805 /* Note that the calculation of OFFSET might overflow; we calculate it so
806 that we still get the right result as long as ALIGN is a power of two. */
807 unsigned HOST_WIDE_INT offset = byte_offset * BITS_PER_UNIT + bit_offset;
808
809 offset = offset % align;
810 return ((offset + size + align - 1) / align
811 > ((unsigned HOST_WIDE_INT) tree_low_cst (TYPE_SIZE (type), 1)
812 / align));
813 }

Notice the(offset + size + align - 1) / align at line 810. It rounds up offset+size to closest times of align. And line 811 works out the ratio of size of the type to the type alignment (for example, in x86, double has ratio of 2). If the bit field declaration stride alignment boundary, bitpos is upgraded to next boundary.
Also find that line 957 indicates that, for GCC layout struct, one field aligned means the whole struct is regarded as aligned. At line 961, BITFIELD_NBYTES_LIMITED if defined means the bit-field even can’t cross the byte boundary unless it fully occupies the previous byte. It is not defined in x86 platform.
2.2.3.1.5.2.2.6.5. Alignment – bit field in MS layout
Refer to Treatment for Bit Field Decl for something about MS layout. Here the processing is alike. But it needs to consider the order of the bit-fields appearance, and becomes more complex. Below at line 1024, if rli->prev_field is not NULL, indicates previous field is a bit-field too. And condition at line 1032 promises that both current and previous bit-fields are not of zero size.

place_field (continue)

1000 /* See the docs for TARGET_MS_BITFIELD_LAYOUT_P for details.
1001 A subtlety:
1002 When a bit field is inserted into a packed record, the whole
1003 size of the underlying type is used by one or more same-size
1004 adjacent bitfields. (That is, if its long:3, 32 bits is
1005 used in the record, and any additional adjacent long bitfields are
1006 packed into the same chunk of 32 bits. However, if the size
1007 changes, a new field of that size is allocated.) In an unpacked
1008 record, this is the same as using alignment, but not equivalent
1009 when packing.
1010
1011 Note: for compatibility, we use the type size, not the type alignment
1012 to determine alignment, since that matches the documentation */
1013
1014 if ((* targetm.ms_bitfield_layout_p) (rli->t)
1015 && ((DECL_BIT_FIELD_TYPE (field) && ! DECL_PACKED (field))
1016 || (rli->prev_field && ! DECL_PACKED (rli->prev_field))))
1017 {
1018 /* At this point, either the prior or current are bitfields,
1019 (possibly both), and we're dealing with MS packing. */
1020 tree prev_saved = rli->prev_field;
1021
1022 /* Is the prior field a bitfield? If so, handle "runs" of same
1023 type size fields. */
1024 if (rli->prev_field /* necessarily a bitfield if it exists. */)
1025 {
1026 /* If both are bitfields, nonzero, and the same size, this is
1027 the middle of a run. Zero declared size fields are special
1028 and handled as "end of run". (Note: it's nonzero declared
1029 size, but equal type sizes!) (Since we know that both
1030 the current and previous fields are bitfields by the
1031 time we check it, DECL_SIZE must be present for both.) */
1032 if (DECL_BIT_FIELD_TYPE (field)
1033 && ! integer_zerop (DECL_SIZE (field))
1034 && ! integer_zerop (DECL_SIZE (rli->prev_field))
1035 && host_integerp (DECL_SIZE (rli->prev_field), 0)
1036 && host_integerp (TYPE_SIZE (type), 0)
1037 && simple_cst_equal (TYPE_SIZE (type),
1038 TYPE_SIZE (TREE_TYPE (rli->prev_field))))
1039 {
1040 /* We're in the middle of a run of equal type size fields; make
1041 sure we realign if we run out of bits. (Not decl size,
1042 type size!) */
1043 HOST_WIDE_INT bitsize = tree_low_cst (DECL_SIZE (field), 0);
1044
1045 if (rli->remaining_in_alignment < bitsize)
1046 {
1047 /* out of bits; bump up to next 'word'. */
1048 rli->offset = DECL_FIELD_OFFSET (rli->prev_field);
1049 rli->bitpos
1050 = size_binop (PLUS_EXPR, TYPE_SIZE (type),
1051 DECL_FIELD_BIT_OFFSET (rli->prev_field));
1052 rli->prev_field = field;
1053 rli->remaining_in_alignment
1054 = tree_low_cst (TYPE_SIZE (type), 0);
1055 }
1056
1057 rli->remaining_in_alignment -= bitsize;
1058 }

One of great difference between GCC layout and MS layout is that, for MS layout, adjacent bit fields share the same storage unit only they are of same type. remaining_in_alignment field in record_layout_info records the left bits in the shared storage. If the left bits are not enough for the bit field, it needs to bump up to next alignment boundary. Pay attention to bitpos at line 1048, in MS layout, its effect upon layout is replaced by remaining_in_alignment, but it still records the size of the uncommitted part during layout. There is tricky premise. Since processing bit-field in layout_decl, which will replace type having the closest size as the type of the bit-field, total size of 2 adjacent same type bit-fields must exceed the size of the type.

place_field (continue)

1059 else
1060 {
1061 /* End of a run: if leaving a run of bitfields of the same type
1062 size, we have to "use up" the rest of the bits of the type
1063 size.
1064
1065 Compute the new position as the sum of the size for the prior
1066 type and where we first started working on that type.
1067 Note: since the beginning of the field was aligned then
1068 of course the end will be too. No round needed. */
1069
1070 if (!integer_zerop (DECL_SIZE (rli->prev_field)))
1071 {
1072 tree type_size = TYPE_SIZE (TREE_TYPE (rli->prev_field));
1073
1074 rli->bitpos
1075 = size_binop (PLUS_EXPR, type_size,
1076 DECL_FIELD_BIT_OFFSET (rli->prev_field));
1077 }
1078 else
1079 /* We "use up" size zero fields; the code below should behave
1080 as if the prior field was not a bitfield. */
1081 prev_saved = NULL;
1082
1083 /* Cause a new bitfield to be captured, either this time (if
1084 currently a bitfield) or next time we see one. */
1085 if (!DECL_BIT_FIELD_TYPE(field)
1086 || integer_zerop (DECL_SIZE (field)))
1087 rli->prev_field = NULL;
1088 }
1089
1090 normalize_rli (rli);
1091 }

If enters the block at line 1059, and satisfies the condition at line 1070, it indicates either, 1) 0 size bit-filed following nonzero size bit-field; or 2) current bit-field is also nonzero size but not of same type as previous one; or 3) current field is not bit-field. In MS layout, current field should be placed in the new memory unit. Thus expression at line 1074 is not very correct. In v4.3.0 it now becomes:
rli->bitpos=size_binop (PLUS_EXPR, rli->bitpos, bitsize_int (rli->remaining_in_alignment));
Then if previous bit-field of 0 size, code at line 1081 will be executed.
Next at line 1085, if current field is not bit-field, or it is 0 in size; the next field should be regarded as following non-bit-field.
As we may adjust bitpos above, it is possible bitpos larger than alignment, it needs normalize bitpos and offset. It is the functionality of normalize_rli.

659 void
660 normalize_rli (record_layout_info rli) in stor-layout.c
661 {
662 normalize_offset (&rli->offset, &rli->bitpos, rli->offset_align);
663 }

In normalized form, bitpos must be within alignment boundary.

614 void
615 normalize_offset (tree *poffset, tree *pbitpos, unsigned int off_align) in stor-layout.c
616 {
617 /* If the bit position is now larger than it should be, adjust it
618 downwards. */
619 if (compare_tree_int (*pbitpos, off_align) >= 0)
620 {
621 tree extra_aligns = size_binop (FLOOR_DIV_EXPR, *pbitpos,
622 bitsize_int (off_align));
623
624 *poffset
625 = size_binop (PLUS_EXPR, *poffset,
626 size_binop (MULT_EXPR, convert (sizetype, extra_aligns),
627 size_int (off_align / BITS_PER_UNIT)));
628
629 *pbitpos
630 = size_binop (FLOOR_MOD_EXPR, *pbitpos, bitsize_int (off_align));
631 }
632 }

Below, if current field is, either 1) not bit-field, or bit-field and 2) previous is bit-field, and of different type, or 3) previous is not bit-field and current has nonzero size; condition at line 1105 is satisfied. Notice that for non-bit-field, its DECL_SIZE equates to its type’s TYPE_SIZE, thus for it, remaining_in_alignment at line 1121 is 0. While for bit-field, it is the remained bits from TYPE_SIZE.

place_field (continue)

1093 /* If we're starting a new run of same size type bitfields
1094 (or a run of non-bitfields), set up the "first of the run"
1095 fields.
1096
1097 That is, if the current field is not a bitfield, or if there
1098 was a prior bitfield the type sizes differ, or if there wasn't
1099 a prior bitfield the size of the current field is nonzero.
1100
1101 Note: we must be sure to test ONLY the type size if there was
1102 a prior bitfield and ONLY for the current field being zero if
1103 there wasn't. */
1104
1105 if (!DECL_BIT_FIELD_TYPE (field)
1106 || ( prev_saved != NULL
1107 ? !simple_cst_equal (TYPE_SIZE (type),
1108 TYPE_SIZE (TREE_TYPE (prev_saved)))
1109 : ! integer_zerop (DECL_SIZE (field)) ))
1110 {
1111 /* Never smaller than a byte for compatibility. */
1112 unsigned int type_align = BITS_PER_UNIT;
1113
1114 /* (When not a bitfield), we could be seeing a flex array (with
1115 no DECL_SIZE). Since we won't be using remaining_in_alignment
1116 until we see a bitfield (and come by here again) we just skip
1117 calculating it. */
1118 if (DECL_SIZE (field) != NULL
1119 && host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
1120 && host_integerp (DECL_SIZE (field), 0))
1121 rli->remaining_in_alignment
1122 = tree_low_cst (TYPE_SIZE (TREE_TYPE (field)), 0)
1123 - tree_low_cst (DECL_SIZE (field), 0);
1124
1125 /* Now align (conventionally) for the new type. */
1126 if (!DECL_PACKED(field))
1127 type_align = MAX(TYPE_ALIGN (type), type_align);
1128
1129 if (prev_saved
1130 && DECL_BIT_FIELD_TYPE (prev_saved)
1131 /* If the previous bit-field is zero-sized, we've already
1132 accounted for its alignment needs (or ignored it, if
1133 appropriate) while placing it. */
1134 && ! integer_zerop (DECL_SIZE (prev_saved)))
1135 type_align = MAX (type_align,
1136 TYPE_ALIGN (TREE_TYPE (prev_saved)));
1137
1138 if (maximum_field_alignment != 0)
1139 type_align = MIN (type_align, maximum_field_alignment);
1140
1141 rli->bitpos = round_up (rli->bitpos, type_align);
1142
1143 /* If we really aligned, don't allow subsequent bitfields
1144 to undo that. */
1145 rli->prev_field = NULL;
1146 }
1147 }

See that prev_saved at line 1129 is set as 0 when previous is bit-field and 0 size; otherwise it holds the previous bit-field. For current bit-field, it has been included in remaining_in_alignment; but it should be placed at alignment boundary, then at line 1141, bitpos takes this adjustment, which is also the same for non-bit-field.
2.2.3.1.5.2.2.6.6. Update record_layout_info
Now we have collected the alignment and offset of the start bit (via offset and bitpos) for the field, it is time to put this information into FIELD_DECL and updates record_layout_info.

place_field (continue)

1149 /* Offset so far becomes the position of this field after normalizing. */
1150 normalize_rli (rli);
1151 DECL_FIELD_OFFSET (field) = rli->offset;
1152 DECL_FIELD_BIT_OFFSET (field) = rli->bitpos;
1153 SET_DECL_OFFSET_ALIGN (field, rli->offset_align);
1154
1155 /* If this field ended up more aligned than we thought it would be (we
1156 approximate this by seeing if its position changed), lay out the field
1157 again; perhaps we can use an integral mode for it now. */
1158 if (!integer_zerop (DECL_FIELD_OFFSET (field)))
1159 actual_align = (tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1)
1160 & - tree_low_cst (DECL_FIELD_BIT_OFFSET (field), 1));
1161 else if (integer_zerop (DECL_FIELD_OFFSET (field)))
1162 actual_align = BIGGEST_ALIGNMENT;
1163 else if (host_integerp (DECL_FIELD_OFFSET (field), 1))
1164 actual_align = (BITS_PER_UNIT
1165 * (tree_low_cst (DECL_FIELD_OFFSET (field), 1)
1166 & - tree_low_cst (DECL_FIELD_OFFSET (field), 1)));
1167 else
1168 actual_align = DECL_OFFSET_ALIGN (field);
1169
1170 if (known_align != actual_align)
1171 layout_decl (field, actual_align);
1172
1173 /* Only the MS bitfields use this. */
1174 if (rli->prev_field == NULL && DECL_BIT_FIELD_TYPE(field))
1175 rli->prev_field = field;
1176
1177 /* Now add size of this field to the size of the record. If the size is
1178 not constant, treat the field as being a multiple of bytes and just
1179 adjust the offset, resetting the bit position. Otherwise, apportion the
1180 size amongst the bit position and offset. First handle the case of an
1181 unspecified size, which can happen when we have an invalid nested struct
1182 definition, such as struct j { struct j { int i; } }. The error message
1183 is printed in finish_struct. */
1184 if (DECL_SIZE (field) == 0)
1185 /* Do nothing. */;
1186 else if (TREE_CODE (DECL_SIZE_UNIT (field)) != INTEGER_CST
1187 || TREE_CONSTANT_OVERFLOW (DECL_SIZE_UNIT (field)))
1188 {
1189 rli->offset
1190 = size_binop (PLUS_EXPR, rli->offset,
1191 convert (sizetype,
1192 size_binop (CEIL_DIV_EXPR, rli->bitpos,
1193 bitsize_unit_node)));
1194 rli->offset
1195 = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field));
1196 rli->bitpos = bitsize_zero_node;
1197 rli->offset_align = MIN (rli->offset_align, desired_align);
1198 }
1199 else
1200 {
1201 rli->bitpos = size_binop (PLUS_EXPR, rli->bitpos, DECL_SIZE (field));
1202 normalize_rli (rli);
1203 }
1204 }

Notice that the order of assigning actual_align is the same as that of known_align at line 862. If both are unequal, calls layout_decl to re-layout the field again; for bit-field may be this time an integer mode can be found.
Since the field has been placed, it is time to adjust parameters in rli. And in layout of nonconstant size, offset_align must be synchronized.
2.2.3.1.5.2.3. Finialize the layout
After finishing layout of all fields, at line 1748 in layout_type, lang_adjust_rli is hook that front-end can set for providing special treatment. In current version, it is useless (and in v4.3.0, it is remvoed). Following, it is going to finialize the size, alignment, etc of the structure.

1444 void
1445 finish_record_layout (record_layout_info rli, int free_p) in stor-layout.c
1446 {
1447 /* Compute the final size. */
1448 finalize_record_size (rli);
1449
1450 /* Compute the TYPE_MODE for the record. */
1451 compute_record_mode (rli->t);
1452
1453 /* Perform any last tweaks to the TYPE_SIZE, etc. */
1454 finalize_type_size (rli->t);
1455
1456 /* Lay out any static members. This is done now because their type
1457 may use the record's type. */
1458 while (rli->pending_statics)
1459 {
1460 layout_decl (TREE_VALUE (rli->pending_statics), 0);
1461 rli->pending_statics = TREE_CHAIN (rli->pending_statics);
1462 }
1463
1464 /* Clean up. */
1465 if (free_p)
1466 free (rli);
1467 }
2.2.3.1.5.2.3.1. Determine Size of the Type
Function finalize_record_size computes the final size of aggregate type out of given record_layout_info.

1210 static void
1211 finalize_record_size (record_layout_info rli) in stor-layout.c
1212 {
1213 tree unpadded_size, unpadded_size_unit;
1214
1215 /* Now we want just byte and bit offsets, so set the offset alignment
1216 to be a byte and then normalize. */
1217 rli->offset_align = BITS_PER_UNIT;
1218 normalize_rli (rli);
1219
1220 /* Determine the desired alignment. */
1221 #ifdef ROUND_TYPE_ALIGN
1222 TYPE_ALIGN (rli->t) = ROUND_TYPE_ALIGN (rli->t, TYPE_ALIGN (rli->t),
1223 rli->record_align);
1224 #else
1225 TYPE_ALIGN (rli->t) = MAX (TYPE_ALIGN (rli->t), rli->record_align);
1226 #endif
1227
1228 /* Compute the size so far. Be sure to allow for extra bits in the
1229 size in bytes. We have guaranteed above that it will be no more
1230 than a single byte. */
1231 unpadded_size = rli_size_so_far (rli);
1232 unpadded_size_unit = rli_size_unit_so_far (rli);
1233 if (! integer_zerop (rli->bitpos))
1234 unpadded_size_unit
1235 = size_binop (PLUS_EXPR, unpadded_size_unit, size_one_node);
1236
1237 /* Round the size up to be a multiple of the required alignment. */
1238 TYPE_SIZE (rli->t) = round_up (unpadded_size, TYPE_ALIGN (rli->t));
1239 TYPE_SIZE_UNIT (rli->t) = round_up (unpadded_size_unit,
1240 TYPE_ALIGN (rli->t) / BITS_PER_UNIT);
1241
1242 if (warn_padded && TREE_CONSTANT (unpadded_size)
1243 && simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0)
1244 warning ("padding struct size to alignment boundary");
1245
1246 if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
1247 && TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
1248 && TREE_CONSTANT (unpadded_size))
1249 {
1250 tree unpacked_size;
1251
1252 #ifdef ROUND_TYPE_ALIGN
1253 rli->unpacked_align
1254 = ROUND_TYPE_ALIGN (rli->t, TYPE_ALIGN (rli->t), rli->unpacked_align);
1255 #else
1256 rli->unpacked_align = MAX (TYPE_ALIGN (rli->t), rli->unpacked_align);
1257 #endif
1258
1259 unpacked_size = round_up (TYPE_SIZE (rli->t), rli->unpacked_align);
1260 if (simple_cst_equal (unpacked_size, TYPE_SIZE (rli->t)))
1261 {
1262 TYPE_PACKED (rli->t) = 0;
1263
1264 if (TYPE_NAME (rli->t))
1265 {
1266 const char *name;
1267
1268 if (TREE_CODE (TYPE_NAME (rli->t)) == IDENTIFIER_NODE)
1269 name = IDENTIFIER_POINTER (TYPE_NAME (rli->t));
1270 else
1271 name = IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (rli->t)));
1272
1273 if (STRICT_ALIGNMENT)
1274 warning ("packed attribute causes inefficient alignment for `%s'", name);
1275 else
1276 warning ("packed attribute is unnecessary for `%s'", name);
1277 }
1278 else
1279 {
1280 if (STRICT_ALIGNMENT)
1281 warning ("packed attribute causes inefficient alignment");
1282 else
1283 warning ("packed attribute is unnecessary");
1284 }
1285 }
1286 }
1287 }

Line 1217 and 1218 adjust the final size into bytes and the remaining. Then at line 1221, ROUND_TYPE_ALIGN is not defined for x86. At line 1231, 1232, it finds out how many bits and bytes the struct actually occupies now.

675 tree
676 rli_size_so_far (record_layout_info rli) in stor-layout.c
677 {
678 return bit_from_pos (rli->offset, rli->bitpos);
679 }

582 tree
583 bit_from_pos (tree offset, tree bitpos) in stor-layout.c
584 {
585 return size_binop (PLUS_EXPR, bitpos,
586 size_binop (MULT_EXPR, convert (bitsizetype, offset),
587 bitsize_unit_node));
588 }

667 tree
668 rli_size_unit_so_far (record_layout_info rli)
669 {
670 return byte_from_pos (rli->offset, rli->bitpos);
671 }

590 tree
591 byte_from_pos (tree offset, tree bitpos) in stor-layout.c
592 {
593 return size_binop (PLUS_EXPR, offset,
594 convert (sizetype,
595 size_binop (TRUNC_DIV_EXPR, bitpos,
596 bitsize_unit_node)));
597 }

Notice that in byte_from_pos, the number of bytes doesn’t include remaining bits. So at line 1233, if bitpos is nonzero, extra byte will be added
At line 1225, record_align records the biggest alignment among fields; it is used as the alignment for the structure too. And the size of the structure must be times of the alignment.

307 tree
308 round_up (tree value, int divisor) in stor-layout.c
309 {
310 tree arg = size_int_type (divisor, TREE_TYPE (value));
311
312 return size_binop (MULT_EXPR, size_binop (CEIL_DIV_EXPR, value, arg), arg);
313 }

In the rest code, if there is padding at tail and –Wpadded in used, gives out warning. While for packed layout, if the result is the same as that of unpacked, and if –Wpacked in effect, gives out the warning too.
2.2.3.1.5.2.3.2. Determine Type Mode
As data of BLKmode won’t be placed into register (in other words, it only can be accessed indirectly), but for RECORD_TYPE under certain size, it does can fit into register; so it needs to determine appropriate machine mode for these RECORD_TYPE, then the back-end can generate more efficient code.

1291 void
1292 compute_record_mode (tree type) in stor-layout.c
1293 {
1294 tree field;
1295 enum machine_mode mode = VOIDmode;
1296
1297 /* Most RECORD_TYPEs have BLKmode, so we start off assuming that.
1298 However, if possible, we use a mode that fits in a register
1299 instead, in order to allow for better optimization down the
1300 line. */
1301 TYPE_MODE (type) = BLKmode;
1302
1303 if (! host_integerp (TYPE_SIZE (type), 1))
1304 return;
1305
1306 /* A record which has any BLKmode members must itself be
1307 BLKmode; it can't go in a register. Unless the member is
1308 BLKmode only because it isn't aligned. */
1309 for (field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
1310 {
1311 if (TREE_CODE (field) != FIELD_DECL)
1312 continue;
1313
1314 if (TREE_CODE (TREE_TYPE (field)) == ERROR_MARK
1315 || (TYPE_MODE (TREE_TYPE (field)) == BLKmode
1316 && ! TYPE_NO_FORCE_BLK (TREE_TYPE (field))
1317 && !(TYPE_SIZE (TREE_TYPE (field)) != 0
1318 && integer_zerop (TYPE_SIZE (TREE_TYPE (field)))))
1319 || ! host_integerp (bit_position (field), 1)
1320 || DECL_SIZE (field) == 0
1321 || ! host_integerp (DECL_SIZE (field), 1))
1322 return;
1323
1324 /* If this field is the whole struct, remember its mode so
1325 that, say, we can put a double in a class into a DF
1326 register instead of forcing it to live in the stack. */
1327 if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
1328 mode = DECL_MODE (field);
1329
1330 #ifdef MEMBER_TYPE_FORCES_BLK
1331 /* With some targets, eg. c4x, it is sub-optimal
1332 to access an aligned BLKmode structure as a scalar. */
1333
1334 if (MEMBER_TYPE_FORCES_BLK (field, mode))
1335 return;
1336 #endif /* MEMBER_TYPE_FORCES_BLK */
1337 }
1338
1339 /* If we only have one real field; use its mode. This only applies to
1340 RECORD_TYPE. This does not apply to unions. */
1341 if (TREE_CODE (type) == RECORD_TYPE && mode != VOIDmode)
1342 TYPE_MODE (type) = mode;
1343 else
1344 TYPE_MODE (type) = mode_for_size_tree (TYPE_SIZE (type), MODE_INT, 1);
1345
1346 /* If structure's known alignment is less than what the scalar
1347 mode would need, and it matters, then stick with BLKmode. */
1348 if (TYPE_MODE (type) != BLKmode
1349 && STRICT_ALIGNMENT
1350 && ! (TYPE_ALIGN (type) >= BIGGEST_ALIGNMENT
1351 || TYPE_ALIGN (type) >= GET_MODE_ALIGNMENT (TYPE_MODE (type))))
1352 {
1353 /* If this is the only reason this type is BLKmode, then
1354 don't force containing types to be BLKmode. */
1355 TYPE_NO_FORCE_BLK (type) = 1;
1356 TYPE_MODE (type) = BLKmode;
1357 }
1358 }

Next, based on finalize_record_size, finalize_type_size does some small tweaks, and applies the finalized parameters upon type variants. And for type having non-constant size, it also will invoke variable_size to create SAVE_EXPR to prevent compiler from doing extra evaluation.
At last, it processes all pending static variable declarations.