v2: implement native x64 backend, part 2#27365
Merged
Merged
Conversation
medvednikov
added a commit
that referenced
this pull request
Jun 6, 2026
…regression, part 2) Two transform-phase arm64 miscompiles from e78b731 (#27365) made every v3-compiled binary crash (`array.push: negative len` / exit 137): - types.v type_from_init_expr: e78 added type_to_c_name() guards + a trailing Struct{} fallback. On arm64 an array/map types.Type can arrive with an invalid native sumtype payload (type_has_valid_payload=false -> empty c_name), so the guards drop it into the Struct{} fallback; the init is then lowered as a struct -> garbage array -> negative-len push. Restore the original graceful behaviour (return the normalized type, else none) so it degrades instead of fabricating a wrong struct type. - fn.v call_fn_info_for_lhs: revert e78's changes here. The has_current_module_ concrete_fn fast-path relies on a sumtype unbox (obj is Fn -> get_typ() -> is FnType -> get_generic_params()) the arm64 backend miscompiles, mis-resolving concrete calls like println; the generic-aware type-construction helpers have further arm64-fragile patterns. They are generic/x64-oriented and dead in the generic-free self-host, so a715's fn.v is the validated config here. With part 1 (mut []T param append, d2e2a95) this restores the full arm64 self-host: v3->v4 reaches a fixpoint and cmd/v2/test_all.sh passes (ALL TESTS PASSED). The reverted e78 transformer changes still need an arm64-compatibility pass for x64.
dy-tea
pushed a commit
to wenxuanjun/v
that referenced
this pull request
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is part 2 of the V2 native x64 backend.
It extends the backend enough to compile and run more real V examples across Linux, macOS x64, and Windows x64, while keeping the tiny/native output path for small eligible programs and falling back to the normal path when needed.
Added support
The x64 backend now covers the existing part 1 / part 1b examples, plus additional examples such as:
examples/hello_world.vexamples/fizz_buzz.vexamples/js_hello_world.vexamples/vascii.vexamples/rune.vexamples/hanoi.vexamples/fibonacci.vexamples/function_types.vexamples/submodule/main.vexamples/sudoku.vexamples/tree_of_nodes.vexamples/graphs/bfs.vexamples/graphs/dfs.vexamples/graphs/dijkstra.vTesting
Added/extended regression coverage for the new x64 backend behavior and wired the supported examples into the Linux, macOS x64, and Windows x64 CI checks.
Validated locally with:
./v fmt -verify vlib/v2/gen/x64/x64_runtime_smoke_test.v./v test vlib/v2/builder/native_test.v vlib/v2/builder/target_os_test.v./v test vlib/v2/ssa/optimizeV2_VERIFY_STRICT=1 ./v test vlib/v2/ssa/optimizeVJOBS=1 ./v test vlib/v2/abi vlib/v2/gen/x64