[quaesitor-scientiam]

Summary

vlang/v's vc/v_win.c bootstrap snapshot is always generated with
-cc msvc (see vlang/v's .github/workflows/gen_vc_ci.yml), which
makes its cgen emit unconditional #include <intrin.h> and
#include <dbghelp.h> under #ifdef _WIN32 (see vlang/v's
vlib/v/gen/c/cleanc.v, the g.ccompiler == 'msvc' branch). This
toolchain ships neither header, so ./makev.bat's default TCC-first
bootstrap path fails immediately on a fresh Windows clone of vlang/v,
before reaching any real code:

./vc/v_win.c:1168: error: include file 'intrin.h' not found

This PR adds both headers:

• include/intrin.h — an empty compatibility stub (see the file's own
  comment for why: an earlier revision of this PR ported the real
  mingw-w64 header, but include/_mingw.h unconditionally
  #define __INTRIN_H_ — that header's own guard — so with
  <windows.h> included first (the real vc/v_win.c order), its body
  was silently skipped entirely, and used standalone it failed outright
  on missing crtdefs.h/psdk_inc/intrin-impl.h, neither shipped in
  this bundle; caught by @medvednikov's review, reverted in 2a102c9).
  None of the MSVC intrinsics vlang's cgen can emit (_umul128,
  _udiv128, _addcarry_u64, _BitScanForward, _BitScanForward64)
  are ever actually called when tcc compiles vc/v_win.c — every call
  site is wrapped in #if defined(_MSC_VER) at the C level — and
  _BitScanForward/_BitScanForward64/__faststorefence are already
  implemented for tcc in include/winapi/winnt.h via
  vlang-header-compat.patch. So the stub costs nothing.
• include/dbghelp.h — the real mingw-w64 header (public domain, no
  copyright assigned — same provenance as the include/winapi/*.h
  files already vendored in this bundle), plus its small dependency
  chain: include/psdk_inc/_dbg_LOAD_IMAGE.h,
  include/psdk_inc/_dbg_common.h, and the pack-pragma helpers
  include/pshpack4.h / include/poppack.h. Unlike intrin.h, this
  one is NOT include-order-independent — its own top comment (added in
  da89255) documents that it requires <windows.h> first, which
  matches vc/v_win.c's actual order and is not a problem for this
  bundle's only consumer.

This change is additive: it lets the #include lines resolve, with no
risk of redefinition (verified) or behavior change to existing code.

Test plan

• Fresh vlang/v checkout (commit c4998cf, later 73956465)
  with this bundle's include/ copied into thirdparty/tcc/:
  ./makev.bat -tcc bootstraps successfully end-to-end (previously
  failed at the intrin.h #include on the very first line of
  output).
• ./v.exe run examples/hello_world.v succeeds with the resulting
  compiler.
• ./v.exe test vlib/math/bits/ passes (exercises the
  $if msvc/$else branches these headers touch).
• Reviewer's exact repro (#include <intrin.h> alone, tcc.exe -c)
  passes against the current stub; confirmed it fails against the
  earlier real-header revision.
• Two rounds of an independent adversarial-review workflow run
  against this PR; the one confirmed finding (the dbghelp.h
  order-dependence gap above) is fixed and documented.
• Not yet verified against thirdparty-windows-i386 — this PR only
  targets windows-amd64.

🧙 Built with WOZCODE

[medvednikov]

Reviewed 65dc75a174e83652cab0b6f65c5700fc684759d9, without considering CI status or results.

One actionable finding (P2): intrin.h has an include-order-dependent missing-dependency failure. Details and a minimal reproduction are attached inline.

An important distinction: this does not establish a failure of the reported V bootstrap. The bundled include/_mingw.h defines __INTRIN_H_, so including the normal TCC/Windows headers first skips the entire new intrin.h body, not just its SSE/AVX branches. That can satisfy the bootstrap's include directive without demonstrating that the imported intrinsic declarations are usable.

I also checked the added DbgHelp dependency headers and the paired packing helpers; I did not identify another bundle-integration finding in that inspection.

Validation was source inspection of the PR, the bundled header guards/dependency paths, and relevant upstream sources. I did not run a Windows/TCC compilation, a V bootstrap, or the V test suite locally.

[medvednikov]

Rechecked the fix at 2a102c922b42aa793111e06d33c58f1e0ff17aee, without considering CI status or results.

The previous P2 finding is addressed. No new actionable correctness findings in the revised intrin.h.

The replacement is a dependency-free compatibility stub with its own TCC_INTRIN_H_SHIM guard. It no longer includes the missing crtdefs.h or psdk_inc/intrin-impl.h, and it does not depend on _mingw.h having already defined __INTRIN_H_. It preserves the intended no-op for the bootstrap's include directive without introducing declarations or definitions that could conflict with the bundled Windows headers. Its comments now explicitly describe the limited scope rather than claiming a full intrinsic implementation.

Validation: compiled the fetched 36-line header in isolation with GCC 14.2 on Linux using -std=c11 -Wall -Wextra -Werror -nostdinc and only the isolated header directory on the include path. Repeated inclusion passed in all four configurations: __INTRIN_H_ defined/undefined, each with and without _WIN32/_WIN64 defined. These are header self-containment checks, not Windows/TCC integration tests. I did not run the bundled Windows compiler, the actual windows.h include-order combinations, a V bootstrap, or the V test suite locally.

Non-blocking documentation note: please update the PR description, which still describes intrin.h as an unmodified real MinGW-w64 header with inactive SSE/AVX branches. That no longer matches the deliberately empty compatibility stub.

[quaesitor-scientiam]

Ran an adversarial review pass on this PR (5 independent lenses, 3 adversarial refuters per candidate finding). One confirmed, real gap: dbghelp.h doesn't have the same order-independence property intrin.h's empty stub does - its dependency psdk_inc/_dbg_LOAD_IMAGE.h uses PSTR/PUCHAR/HANDLE/etc. without defining or including them, relying on <windows.h> having already run. Verified live: #include <intrin.h> then #include <dbghelp.h> without windows.h first fails (psdk_inc/_dbg_LOAD_IMAGE.h:24: ';' expected (got 'PSTR')); the actual vc/v_win.c order (windows.h, then intrin.h, then dbghelp.h) still compiles clean, so this doesn't affect the real build. Documented the requirement directly in dbghelp.h in da89255 rather than vendoring more of windows.h's typedef surface (which risks conflicting redefinitions and doesn't match this bundle's only actual consumer's include order anyway).

The other candidate findings from that review didn't survive adversarial verification, and I found no other guard-collision or missing-dependency issue beyond this one.

[quaesitor-scientiam]

Thanks for the recheck. Updated the PR description to describe the actual current state (empty stub for intrin.h, real header + documented include-order requirement for dbghelp.h) rather than the abandoned real-header approach.

[JalonSolov]

Does this change also need to be made to windows-i386 branch?

[quaesitor-scientiam]

Yes - checked before assuming: `thirdparty-windows-i386`'s `include/_mingw.h` predefines `_INTRIN_H` at the same spot (line 140 vs 146 on amd64), and neither `intrin.h` nor `dbghelp.h` exists on that branch either, so it has the identical gap this PR fixes.

Opened a companion PR: #98

[medvednikov]

Reviewed the current six-file change at da89255a949156be032ee75372857bd2edf4898b, including the revised intrinsic shim and DbgHelp dependency/packing integration. CI status/results were excluded.

No new actionable correctness issue found in the header integration reviewed. The earlier intrinsic-header dependency finding remains fixed, and the description now accurately identifies the empty shim.

intrin.h uses its own TCC_INTRIN_H_SHIM guard and introduces neither external dependencies nor intrinsic declarations. In particular, it no longer relies on an earlier Windows/CRT header defining __INTRIN_H_ to hide missing includes. This is an include-compatibility shim, not a general implementation of MSVC intrinsics.

For DbgHelp, the added _dbg_LOAD_IMAGE.h and _dbg_common.h include chain is present, _mingw_unicode.h is an existing bundle dependency, and the new push/pop packing headers pair correctly around the minidump declarations. The common header's Git blob SHA (aa94da4a79260cc06e801c37d6343a3efbda5a48) exactly matches the upstream mingw-w64 file I fetched and the i386 companion PR. The _WIN64-conditional _IMAGEHLP64 selection preserves the architecture-specific aliases rather than forcing them on every target.

The added dbghelp.h comment correctly discloses that <windows.h> must precede it; this change does not make that header self-contained, and the intrinsic-shim self-containment check should not be presented as a DbgHelp integration check.

Local validation: 12 isolated Clang syntax/layout probes across i686 and x86_64 Windows targets, using the fetched shim/packing helpers' active contents, with __INTRIN_H_ defined/undefined and normal/RC_INVOKED/lint configurations. Repeated inclusion, four-byte packing, and restoration of incoming packing passed. The expected Clang warning about a packing helper deliberately changing alignment across an include was disabled (-Wno-pragma-pack); layout/restoration were checked with static assertions.

Limits: these small probes do not compile the entire bundled Windows header tree. I did not run Windows TinyCC, link a DbgHelp caller, execute a V bootstrap, or run V tests. No Windows interpreter or V compiler is installed locally, and direct checkout downloads fail DNS resolution. The author's end-to-end amd64 reports are not claimed as my own executions.

[quaesitor-scientiam]

Thanks for the thorough re-review - appreciate the independent blob-SHA cross-check against the i386 companion and the Clang probes across both pointer widths.

Follow-up on the i386 side, in case useful context: #98 (the companion PR you cross-checked) went through its own adversarial review and picked up two comment-accuracy fixes (a stale line-number reference and an inherited "verified to build" claim that wasn't true for that branch - both fixed in 2893cc1). Pushing further to actually get a real i386 build running turned up something bigger and unrelated to either PR's header content: thirdparty-windows-i386's bundled tcc.exe is a much older build (0.9.27, stock 2017) than amd64's (0.9.28rc, a newer custom fork) and can't compile vc/v_win.c at all past a _Bool/C11-atomics line, even with every header gap patched. Opened that as #99 since it's a toolchain-provenance question, not a header fix. Also found and fixed one more small header gap along the way (winapi/psapi.h, missing entirely from i386) in #100.

None of that changes anything about this PR - just flagging in case the i386 toolchain-version question in #99 is relevant to how you'd want to sequence merging the i386-side PRs.