🏠 ESL - Engineering Software Lab Parasoft CUDA Bridge · Technical evaluation brief
Technical evaluation brief · 01

Bring CUDA source into a reviewable C++test workflow

Parasoft CUDA Bridge for Visual Studio 2026: implementation map, CUDA rule scope, test evidence, known limits, and questions for the Parasoft C++test product team

36
NVIDIA CUDA C++ Guidelines 3.0.1 rule identifiers in the ESL rule pack, implemented as heuristic source checks
CMake + native
CUDA projects analyzed through generated Visual Studio companion solutions, with findings brought back into the IDE
Daniel Liezrowice
Daniel Liezrowice CTO, ESL - Engineering Software Lab

Embedded software consultancy, Parasoft and Perforce partner in Israel for over 20 years. ESL builds and supports the Parasoft CUDA Bridge.

linkedin.com/in/liezrowice
Engineering Software Lab Ltd. · 26 October 2026 · Evaluation material, not a release announcement
The integration gap · 02

CUDA source enters the build through a different project item

C/C++test scopes ClCompile items; CUDA files are compiled through CudaCompile

C++test boundary

Host C/C++ scope

C/C++test Professional scopes the familiar ClCompile extensions: .c, .cc, .cpp, and .cxx.

CUDA boundary

.cu uses CudaCompile

The CUDA build task is not a standard C++ compile item. The Bridge creates C++-recognizable companion inputs so C++test can analyze host-visible CUDA source.

vectorAdd.cu ── CudaCompile ──► nvcc (not in C/C++test scope) │ └─► Bridge mirror vectorAdd.cu.cpp ── ClCompile ──► C/C++test ──► findings mapped to vectorAdd.cu
This is a compatibility workflow around the existing analyzer, not a claim that C++test has become a native CUDA semantic analyzer.
Components · 03

A small adapter around installed engineering tools

One native CLI, one Visual Studio extension, one local rule pack

Native CLI

Prepare and run

pcb.exe is a .NET 10 NativeAOT win-x64 tool. It generates companion solutions, installs local rules, invokes analysis, maps findings, and runs supported tests.

Visual Studio extension

Bring actions into VS

The net472 VSIX adds Parasoft CUDA commands, activation and legal UI, rule selection, configuration management, Error List findings, and editor squiggles.

Local rule pack

CUDA guidance checks

Python rule scripts are generated into Parasoft RuleWizard files at build time. The source checks remain heuristic and are not a complete C++ front end.

The VSIX bundles the native CLI and ESL rule assets. It does not include Parasoft, CUDA Toolkit, the issuer, or a token-signing private key.
CMake path · 04

CMake prepares a Visual Studio analysis solution

Six steps from a CMake CUDA folder to mapped findings

1ConfigureUse the Visual Studio 2026 CMake generator and the customer's toolchain.
2Evaluate projectsRead evaluated MSBuild metadata, including CUDA and C/C++ items and properties.
3Capture host flagsUse nvcc --dryrun to collect host defines, include paths, and options.
4Generate companionsCreate analysis .vcxproj files and .cu.cpp source mirrors.
5AnalyzeRun C/C++test on the generated *-parasoft.sln.
6Map resultsWrite reports and findings JSON, then publish locations against original CUDA files.
Important: this is not native CMake-engine integration. Generate the companion solution first, then analyze that solution.
Source fidelity · 05

Keep host-side compiler context close to nvcc

The companion project mirrors what nvcc would hand to the host compiler

  • One companion project is produced for each CUDA project.
  • Each .cu is mirrored as .cu.cpp, usually as a hard link, with a copy fallback across volumes.
  • Definitions, include paths, forced includes, language options, and host flags come from evaluated build metadata and nvcc's dry-run.
  • Source maps bring findings back to the original .cu path and line.
  • The analyzer project is for analysis, not a replacement build target.
Profile behavior

Use the customer's installation

The per-user CUDA compiler profile is adapted from the locally installed Parasoft profile. ESL does not ship Parasoft's base compiler profile or engine.

nvcc host flagssource mappinglocal profile
CUDA Guidelines 3.0.1 · 06

36 rule identifiers, with explicit heuristic boundaries

Coverage of the NVIDIA CUDA C++ Guidelines for Robust and Safety Critical Programming

36
NVIDIA rule identifiers represented
35
Enabled in the default profile
1
CUDA-2_4 is opt-in for compute capability 6.0 and below
5
Process directives are guidance, not automated checks
The checks are source-pattern heuristics. They can report false positives or miss cases. A clean report is not proof of CUDA guideline compliance.
Reference: NVIDIA CUDA C++ Guidelines for Robust and Safety Critical Programming, v3.0.1. Full rule list in the appendix.
Real Visual Studio evidence · 07

vectorAdd in the companion solution

Genuine local Visual Studio capture: the generated vectorAdd companion solution after one Flow Analysis Standard run
Visual Studio capture showing the generated vectorAdd companion solution, source editor and five findings in the Error List
1 of 1 file, 144 source lines, 5 findings: 3 Very High and 2 High
Findings to review, not confirmed defects
The File column shows the generated .cu.cpp mirror, so this does not prove original-path presentation
Flow Analysis detail · 08

Five Flow Analysis findings, close up

Detail view of the same Flow Analysis Standard run on vectorAdd

Error List detail from the same run: 3 Very High and 2 High findings
Close view of the five vectorAdd Flow Analysis findings

Analyzer output

These are analyzer findings to review against source and build context, not confirmed defects.

Mirror path in this capture

The File column shows the generated .cu.cpp mirror, so this capture does not prove original-path presentation.

CUDA rule findings · 09

CUDA rule findings in native projects

Genuine native CUDA project capture: 16 CUDA heuristic warning entries and one active E0029 entry (Build + IntelliSense)
Visual Studio capture of native CUDA companion projects with CUDA guideline warnings

Heuristic findings in a native Visual Studio capture

Separate run, separate counts

This native-project capture is not the CMake vectorAdd run. Its 16 warning entries are shown as heuristic CUDA findings.

The active E0029 entry is a separate IDE diagnostic. This screenshot is not evidence of a clean build.

Do not combine this warning count with the separate vectorAdd CLI smoke count.
Rule-pack QA · 10

Representative rule validation, not a compliance score

One selected Windows sample, measuring rule execution and output handling

35
Selected Windows-enabled rules
33
Windows targets in the sample run
34
CUDA mirror files exercised
10,587
Source lines in that QA sample

Observed analyzer workload

6,008 StdViol records and zero failed targets in the selected sample. Two Linux-only targets were 0/0 and are not included in the Windows target count.

Interpretation

Violation records are not unique confirmed defects. This sample measures rule execution and output handling, not correctness, completeness, or safety compliance.

Historical stress runs · 11

Keep each repository's scope beside its counts

Large open-source CUDA code bases, analyzed through companion solutions

ProjectStdViolFlowViolFilesLines
llama.cpp40,919559702 / 702376,144
nvbench3,0404045 / 4518,351
MatX888None recorded26 / 286,289 / 6,427
CUTLASS12,18268410 / 41665,829 / 68,202
Historical runs are incomplete and not directly comparable. MatX missed 2 translation units; CUTLASS missed 6, skipped 13 MSBuild-unevaluable projects, and had CCCL preprocessing failures. Do not sum these results or infer full coverage.
CUDA GoogleTest · 12

Native Visual Studio projects can run CUDA tests with host coverage

1Discover testsAdjacent tests\*.cu and *.cpp for native .sln/.vcxproj projects.
2Build host unitsSplit CUDA translation units, instrument host code, then link with nvcc.
3Run and importRun GoogleTest and import test XML and coverage using C/C++test Standard.
3 / 3
Native CUDA GoogleTests passed
26 / 26
Host lines covered in the smoke run
0
Device-kernel lines instrumented
This test workflow is for native Visual Studio projects. CMake-folder test discovery is not supported. Device kernels are exercised through host calls but are not covered.
Visual Studio results · 13

Choose where each run's findings appear

Bridge 0.8.0 asks after every run. This MISRA C++ 2023 run on vectorAdd reported 62 findings.

Bridge 0.8.0 completion prompt in Visual Studio 2026 after a MISRA C++ 2023 run on vectorAdd
Bridge 0.8.0 completion prompt reporting 62 findings with HTML report only, Error List only, Both and None choices

HTML report only

Open the run's HTML report.

Error List only

Publish findings with their C/C++test severity.

Both

HTML report and Error List together.

None

Show nothing now. The files are still written.

Each run writes findings.json and an HTML report. Run kinds keep their own results; the clear command removes Bridge entries.
Visual Studio results · 14

MISRA C++ 2023 run in the Error List

The same run in the Error List (Build + IntelliSense filter), with the C/C++test severity on each finding
Visual Studio Error List showing MISRA C++ 2023 findings with C/C++test severity tags on vectorAdd.cu.cpp
Entries keep the C/C++test severity, for example [High], and double-click opens the source line
This run: 1 of 1 file, 144 source lines, 62 findings across 18 rules (MISRA C++ 2023, Bridge 0.8.0)
Findings are analyzer output to review, not confirmed defects
Activation and authorization · 15

Separate the ESL token from the Parasoft entitlement

Stage 1
30 days
Starts at first successful activation, not at token issuance.
Stage 2
+30 days
Its own period begins when the later stage is activated.
Stage 3
Permanent
No time limit. This does not promise perpetual support.

ESL activation controls

ECDSA P-256 signed tokens, machine binding, versioned DPAPI-protected local state, stage/replay checks, grace handling, and rollback detection.

Parasoft checks are separate

Protected operations validate a genuine Parasoft-signed cpptestcli and run a checked-source analysis probe. An ESL token cannot grant Parasoft features.

Local controls provide tamper resistance, not unbreakable protection. A local administrator can bypass or remove local state; no server-backed revocation is claimed.
Activation in Visual Studio · 16

Activation state in the About dialog

About / Legal Notices in Bridge 0.8.0
Bridge 0.8.0 About dialog with activation state, days left, masked fingerprint, contact links and legal notice buttons

Activation state is visible inside the IDE

  • Version and activation state.
  • Days left in the current stage.
  • The machine fingerprint used to issue a token.
  • Contact links and buttons for each legal document.
Bridge 0.8.0 in Visual Studio 2026. Fingerprint and machine ID are masked in these captures.
Activation in Visual Studio · 17

ESL activation and Parasoft license

Activation and License Status: ESL stage and the separate Parasoft license check
Activation and License Status dialog showing stage 1 trial and a valid Parasoft C/C++test license

One dialog, two independent checks

  • The ESL activation stage, shown here as the stage 1 trial.
  • The Parasoft C/C++test license, checked on its own.
An ESL token cannot grant Parasoft features.
Activation in Visual Studio · 18

Activate with a signed token

Activate: paste a machine-bound PCB1- token issued by ESL
Activate dialog with current activation state and a field for a PCB1 activation token

Machine-bound tokens issued by ESL

  • The dialog shows the current activation state.
  • Paste the PCB1- token issued for this machine's fingerprint.
  • Tokens are ECDSA P-256 signed and machine bound.
Fingerprint and machine ID are masked in these captures.
Feedback requested · 19

Questions for the C++test product team

Integration

What is the supported long-term seam?

Is a generated Visual Studio companion solution the right approach, or is there a preferred C++test extension point for CUDA host analysis?

Profiles and rules

Can Parasoft review the adaptation?

We request feedback on the local compiler-profile patch, RuleWizard generation, and compatibility boundaries.

Test and coverage

How should host-only coverage be presented?

What reporting or UI conventions best distinguish host coverage from non-instrumented device kernels?

Evaluation

Which acceptance criteria matter most?

Rule accuracy, setup friction, result navigation, compatibility, and supported configurations are open review topics.

Boundaries · 20

What this evidence does not establish

  • It does not prove complete C++ or GPU semantic analysis, full repository coverage, or compliance with CUDA guidance.
  • It does not convert CUDA guideline heuristics into MISRA checks. They are separate analysis layers.
  • It does not show CMake-native analysis or CMake-folder GoogleTest coverage.
  • It does not include device-kernel coverage or guarantee findings are true defects.
  • It does not establish Parasoft approval of the profile patch or rule generation.
Requires your own licensed Parasoft C/C++test Professional for Visual Studio. The Bridge is an independent ESL product; no approval or endorsement by Parasoft, NVIDIA or Microsoft is claimed.
Appendix · CUDA rule catalog · 1 of 4 · 21

CUDA Guidelines rule titles

CUDA-1_1Keep device-dependent operations inside program lifetime
CUDA-1_2Synchronize outstanding device work before termination
CUDA-1_3Inspect CUDA interface error results
CUDA-1_4Check launch errors before another CUDA operation
CUDA-1_5Do not manufacture CUdevice handles from integers
CUDA-1_6Follow fork with exec before using CUDA
CUDA-1_7Keep execution specifiers consistent
CUDA-1_8Pass trivial kernel arguments by value
CUDA-1_9Use managed storage for host kernel reference arguments
Titles follow the generated catalog. All checks are heuristic; consult the catalog for each boundary. CUDA-2_4 is opt-in for compute capability 6.0 and below.
Appendix · CUDA rule catalog · 2 of 4 · 22

CUDA Guidelines rule titles

CUDA-1_10Do not guard declarations with CUDA architecture macros
CUDA-1_11Do not redefine CUDA implementation macros
CUDA-1_12Do not write constant memory from device code
CUDA-1_13Do not use thread_local in device code
CUDA-1_14Keep block synchronization uniform
CUDA-2_1Only include participating lanes in warp collectives
CUDA-2_2Use valid power-of-two shuffle widths
CUDA-2_3Include calling and source lanes in warp masks
CUDA-2_4Converge warp synchronization on older GPUs (opt-in)
Titles follow the generated catalog. All checks are heuristic; consult the catalog for each boundary. CUDA-2_4 is opt-in for compute capability 6.0 and below.
Appendix · CUDA rule catalog · 3 of 4 · 23

CUDA Guidelines rule titles

CUDA-3_1Call functions in their declared execution spaces
CUDA-3_2Keep function pointers in their originating execution space
CUDA-3_3Access objects only in accessible execution spaces
CUDA-3_4Use at most one dynamic shared array per kernel
CUDA-3_5Do not alias restricted function arguments
CUDA-4_1Configure every kernel call
CUDA-4_2Only configure kernel functions
CUDA-4_3Do not pass polymorphic kernel arguments by value
CUDA-4_4Keep kernel launch bounds consistent
Titles follow the generated catalog. All checks are heuristic; consult the catalog for each boundary. CUDA-2_4 is opt-in for compute capability 6.0 and below.
Appendix · CUDA rule catalog · 4 of 4 · 24

CUDA Guidelines rule titles

CUDA-S1_1Do not register CUDA callbacks
CUDA-S1_2Do not use device assembly
CUDA-S1_3Do not use device RTTI operators
CUDA-S1_4Do not use long double in device code
CUDA-S1_5Restrict uses of const host variables in device code
CUDA-S1_6Restrict uses of constexpr host variables in device code
CUDA-S2_1Avoid unsafe deduced execution-space member pointers
CUDA-S3_1Do not launch kernels while evaluating launch configuration
CUDA-S3_2Do not launch kernels from device code
Titles follow the generated catalog. All checks are heuristic; consult the catalog for each boundary. CUDA-2_4 is opt-in for compute capability 6.0 and below.
Sources and evidence · 25

Traceable claims, bounded conclusions

Primary reference

NVIDIA CUDA C++ Guidelines 3.0.1

docs.nvidia.com/cuda/cuda-for-tegra-appnote/cudaguideV3.0.1.pdf
36 rules and 5 process directives.

Local engineering evidence

Smoke runs, 26 October 2026

CMake-prepared vectorAdd companion-solution analysis and native CUDA GoogleTest smoke runs. Test logs and reports are local evaluation artifacts.

Validation environment: Visual Studio 2026 18.6.2, CUDA 13.2, CMake 4.2.2, Parasoft C/C++test 2026.1.3, RTX 5080 Laptop (sm_120). Results are specific to this setup.
ESL - Engineering Software Lab

Engineering Software Lab Ltd. · sales@eswlab.com · eswlab.com · Daniel Liezrowice on LinkedIn

← Swipe or use arrow keys →