Skip to content

vms-4b5: resolve the alpha cc1 -O0 union-type-pun 'miscompile' (it is the VMS data model) + DEC C behavior-compat architecture - #995

Merged
baron-3dl merged 2 commits into
mainfrom
work/vms-4b5-cc1-fix
Aug 31, 2026
Merged

baron-3dl merged 2 commits into
mainfrom
work/vms-4b5-cc1-fix

Conversation

@baron-3dl

Copy link
Copy Markdown
Contributor

(A) vms-4b5 — the "silent miscompile" is a phantom bug

The reported alpha-dec-vms cc1 (GCC 14.2.0) "-O0 union-type-pun branch miscompile" is not a codegen bug. Root-caused in the ovmx-cross-alpha-vms container:

  • sizeof(long)==4 on alpha-dec-vms even at -mpointer-size=64 — the OpenVMS C data model (LLP64-shaped, long==32; matches DEC C / VSI C). Not LP64.
  • The test punned a 64-bit double through union { double d; unsigned long u; } — a 32-bit member — capturing only the low 32 bits (ldl, correctly).
  • Branching that zero-extended 32-bit value against the 64-bit constant 0x3FF0000000000000 is provably false, which GCC's front-end correctly folds even at -O0. Proof: an in-range constant (0x12345678) keeps the branch; a runtime comparand keeps the branch; only the out-of-range constant folds.
  • Widen the member to unsigned long long → full-width ldq pun + cmpeq + branch codegens perfectly (verified in emitted asm: 1023<<52 builds the constant, real cmpeq/bne).

Fix (contained, source + docs): crtl_cc1fp_test.c widened to unsigned long long, false LP64/miscompile comments corrected, and it now branches on the punned member as a positive regression (compile+assemble verified in-container). Surface-gaps register §1.3 + item #5 corrected. vms-4b5 closed as not-a-bug.

(B) DEC C behavior-compat architecture (the strategic deliverable)

docs/design-decc-bug-compat-architecture.md. The phantom bug is the canonical example of the tarpit: the risk in the GCC-port lane is not "GCC miscompiles VMS source" but "OVMX assumes LP64/GCC-native semantics and every VMS difference surfaces as a phantom bug or a late divergence."

Recommendation: behavior-compatible with DEC C via an explicit behavior register + differential oracle + authoring-time lint (a "DEC C personality layer" over the GCC 14.2.0 alpha-dec-vms base) — scoped to L1 documented behavior, L2/L3 demand-gated. Never bug-compatible by whack-a-mole. Two operator forks surfaced: preprocessor identity (__DECC vs __GNUC__) and how far L2 goes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01V2jrHU9fdTTfKhB5HBQNQH

baron-3dl and others added 2 commits August 31, 2026 18:33
… is the VMS data model, not a bug

Root-caused the reported alpha-dec-vms cc1 (GCC 14.2.0) "silent miscompile"
of a union-type-punned branch at -O0. It is NOT a codegen fault: on
alpha-dec-vms `long` is 32-bit (LLP64-shaped model, matching DEC C / VSI C on
OpenVMS), so `union { double d; unsigned long u; }` puns a 64-bit double
through a 32-bit member and captures only the low 32 bits. Branching that
(zero-extended) value against the 64-bit constant 0x3FF0000000000000 is
provably-false, which GCC correctly folds away even at -O0 (an in-range
constant, or a runtime comparand, keeps the branch). Proven in the
ovmx-cross-alpha-vms container: sizeof(long)==4 even at -mpointer-size=64;
in-range const -> branch kept, out-of-range -> folded; unsigned long long
member -> full ldq pun + cmpeq + branch codegens correctly.

Fix: widen crtl_cc1fp_test.c's fpbits union to `unsigned long long`, correct
the false LP64/miscompile comments, and branch ON the punned member as a
positive regression (real ldq + cmpeq + branch, verified). Correct the
surface-gaps register (S1.3 + item #5). The broader risk this exposed
(DEC C behavior/data-model compatibility) is the subject of a new design doc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V2jrHU9fdTTfKhB5HBQNQH
…not whack-a-mole

Strategic design fork for the operator (vms-da0 lane). Frames the DEC C /
VSI C compatibility problem the vms-4b5 phantom bug exposed: to compile real
VMS C source unchanged, OVMX must be behavior-compatible with DEC C (data
model, layout, float format, pragmas, macros, extensions, linkage), and
chasing individual divergences program-by-program is a tarpit. Recommends a
declarative DEC C behavior register + differential oracle + authoring-time
lint over the GCC 14.2.0 alpha-dec-vms base (a "DEC C personality layer"),
scoped to L1 documented-behavior compat, with L2/L3 demand-gated. Surfaces
two operator forks: preprocessor identity (__DECC vs __GNUC__) and how far
L2 goes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V2jrHU9fdTTfKhB5HBQNQH
@baron-3dl
baron-3dl merged commit c68e3f6 into main Aug 31, 2026
122 checks passed
@baron-3dl
baron-3dl deleted the work/vms-4b5-cc1-fix branch August 31, 2026 18:50
baron-3dl added a commit that referenced this pull request Aug 31, 2026
…del fix

Feature patch over V0.6-8. Bumps the identity SSOT in step (vms-8328 gate):
OVMX_PRODUCT_VERSION V0.6-8 -> V0.6-9 and os-release VERSION_ID 0.6-8 -> 0.6-9.
Adds the V0.6-9 RELEASE_NOTES entry.

Ships four increments already merged to main (GCC-self-host + networking; NO
cluster-participation claim):
  - DECnet Phase IV engine rung-1 (#997, vms-30e): userspace DECNETD.EXE, Option
    B, AF_PACKET hidden behind a VMS surface, oracle-byte-exact + live on-wire.
  - VMS condition-handling CHF rung-1 (#996, vms-2e72): real SYS$SETEXV + frame-
    chain 4-stage dispatch replacing the emulation.
  - RMS workload over genuine ODS-2 (#999, vms-1b5): versioning ;1/;2, dir enum
    with real File IDs, fail-honest RMS$_FNF. Port CRTL->RMS binding = vms-47e.
  - alpha cc1 -O0 "miscompile" was the VMS data model, not a bug (#995, vms-4b5).

Also excises a latent overclaim in the V0.5-7 shipped-release note (release-eng
domain): "two OVMX nodes form a VMScluster against each other" was the hand-
launched SCS probe pair (initiator+joiner), NOT two booted nodes auto-joining
(vms-110b) — corrected to say so, keeping the real handshake credit.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V2jrHU9fdTTfKhB5HBQNQH
baron-3dl added a commit that referenced this pull request Aug 31, 2026
…del fix (#1001)

Feature patch over V0.6-8. Bumps the identity SSOT in step (vms-8328 gate):
OVMX_PRODUCT_VERSION V0.6-8 -> V0.6-9 and os-release VERSION_ID 0.6-8 -> 0.6-9.
Adds the V0.6-9 RELEASE_NOTES entry.

Ships four increments already merged to main (GCC-self-host + networking; NO
cluster-participation claim):
  - DECnet Phase IV engine rung-1 (#997, vms-30e): userspace DECNETD.EXE, Option
    B, AF_PACKET hidden behind a VMS surface, oracle-byte-exact + live on-wire.
  - VMS condition-handling CHF rung-1 (#996, vms-2e72): real SYS$SETEXV + frame-
    chain 4-stage dispatch replacing the emulation.
  - RMS workload over genuine ODS-2 (#999, vms-1b5): versioning ;1/;2, dir enum
    with real File IDs, fail-honest RMS$_FNF. Port CRTL->RMS binding = vms-47e.
  - alpha cc1 -O0 "miscompile" was the VMS data model, not a bug (#995, vms-4b5).

Also excises a latent overclaim in the V0.5-7 shipped-release note (release-eng
domain): "two OVMX nodes form a VMScluster against each other" was the hand-
launched SCS probe pair (initiator+joiner), NOT two booted nodes auto-joining
(vms-110b) — corrected to say so, keeping the real handshake credit.


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

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant