[Windows][JIT] DG_TRAP selects host-only __debugbreak() in CUDA device code

[rogeroberg]

Background

I encountered this issue while running SystemPanic/vllm-windows with DeepSeek-V4-Flash-0731 on 4 x H200 NVL GPUs.

This issue covers the device-trap definition in:

deep_gemm/include/deep_gemm/common/exception.cuh

Problem

The SystemPanic Windows branches currently define DG_TRAP as:

#ifdef _MSC_VER
#define DG_TRAP() __debugbreak()
#else
#define DG_TRAP() asm("trap;")
#endif

DG_TRAP() is used by DG_DEVICE_ASSERT in CUDA device code.

When NVCC uses MSVC as the host compiler, _MSC_VER is also defined while processing device code. The macro therefore selects:

__debugbreak()

However, __debugbreak() is a host-side MSVC breakpoint intrinsic and is not valid in CUDA device code.

This can prevent compilation when a device-code path containing DG_DEVICE_ASSERT is instantiated.

Current deepseek-ai/DeepGEMM main and the SystemPanic main branch instead use:

#define DG_TRAP() asm("trap;")

The _MSC_VER override appears to be specific to the SystemPanic Windows branches.

Tested fix

The working downstream build removes the _MSC_VER override:

- #ifdef _MSC_VER
- #define DG_TRAP() __debugbreak()
- #else
  #define DG_TRAP() asm("trap;")
- #endif

The resulting definition is:

#define DG_TRAP() asm("trap;")

This matches the implementation currently used by both deepseek-ai/DeepGEMM main and the SystemPanic main branch.

Semantics

The change preserves the intended device-assertion behavior:

assertion failure
-> diagnostic output
-> CUDA device trap

The inline PTX instruction:

asm("trap;")

is valid in CUDA device code regardless of whether NVCC uses GCC, Clang, or MSVC as the host compiler.

Linux behavior is unchanged because the non-MSVC path already uses the same PTX trap.

The change only affects assertion-failure handling. It does not affect normal execution, numerical behavior, generated kernel logic, or performance.

Environment

• Windows Server 2025
• Visual Studio Build Tools with MSVC
• CUDA/NVCC 13.2
• Python 3.12
• PyTorch 2.11.0+cu130
• SystemPanic/vllm-windows 0.25-based deployment
• SystemPanic/DeepGEMM-windows dependency
• DeepSeek-V4-Flash-0731
• 4 x H200 NVL GPUs, SM90a