[staalmannen]

… the rule

The VM run matched every number written down before it: long 4, an_il_header 184 against the host's 208, a_scope_pointers_block 168 against 160, and the two folded offsets 408 and 424 against the baked 400 and 416. The two halves were independent -- the il_header difference is the five unsigned long and is exactly the 24 of 424-400, so the fold did use kencc's long; the scope_pointers_block difference is the bit-field container.

408 is where the orphan array was filed and 400 is exported_template_file, so the registration wrote the pointer over a different live member as well as leaving its own null. The 0x68 fault is the second consequence; the first has not been looked for.

The knob is TARG_MICROSOFT_BIT_FIELD_ALLOCATION. kencc_targ.h sets no bit-field variable at all. targ_bit_field_container_size is not it: upstream's comment says -1 already means the base type, a four-byte container, and EDG still started the following char at the next byte, so that variable governs alignment rather than sharing. The sharing one is a TARG_ macro rather than a command-line flag, which a pre-include can set, and one of the eight shipped configurations already uses it.

Scope is the corpus rather than the struct: EDG emits explicit padding after every bit-field group, 33 of 33 in src/il.c and 958 across 74 files, so one rule decides all of them.

Section 2 of the probe decides whether the knob is the fix. The identification that kencc's rule is MSVC's is recalled rather than measured, and a 2.9M-line regeneration is too much to rest on that, so it asks pcc about struct{unsigned x:1; char c;}. The gcc control fires with 1 and 4, the shared container. What cpfe would emit under the knob is deliberately absent: only a rebuilt cpfe can say.

Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs