[tgrogers]

Three independent build fixes needed to compile GPGPU-Sim on a GB300 (Grace-Blackwell, aarch64) with CUDA 13.2. Each is guarded, so x86 builds and pre-13 toolkits are bit-for-bit unchanged.

Companion to accel-sim/gpu-app-collection#91 (application-side CUDA 13 port) and accel-sim/accel-sim-framework#575 (hardware-run and tracer fixes).

1. AccelWattch passed x86-only SSE flags unconditionally

src/accelwattch/CMakeLists.txt added -msse2 -mfpmath=sse to every release build. These are x86 options; aarch64 and ppc64le compilers reject them outright, so all 75 AccelWattch translation units failed before a single line was parsed.

Guarded on CMAKE_SYSTEM_PROCESSOR. The flags are an optimisation hint for x86 FP codegen, not a correctness requirement, so there is nothing to replace them with elsewhere.

2. cudaDeviceProp::clockRate was removed in CUDA 13

GPGPUSim_Init() assigned prop->clockRate = the_gpu->shader_clock(). CUDA 13 dropped clockRate, memoryClockRate and computeMode from cudaDeviceProp in favour of cudaDeviceGetAttribute(cudaDevAttrClockRate), so the assignment stopped compiling.

Guarded on CUDART_VERSION < 13000, matching the #if (CUDART_VERSION >= 2010) style already used a few lines below. Older toolkits keep reporting the shader clock exactly as before.

Worth noting for a follow-up: on CUDA 13 a guest application calling cudaDeviceGetAttribute(cudaDevAttrClockRate) will not get the simulated shader clock, because nothing in libcuda services that attribute yet. This PR only restores the build; wiring the attribute through is a separate change, and no benchmark in the collection currently depends on it.

3. asm("int $03") is an x86 instruction

sst_gpgpu_sim::SST_cycle() used a raw int $03 to break into an attached debugger under -gpgpu_single_step. The assembler rejects it on aarch64.

Now brk #0 on aarch64, int $03 on x86, and __builtin_trap() as a portable fallback. Same debugger behaviour.

Testing

Built on a GB300 (aarch64, CUDA 13.2, driver 610.43.02) via the CMake flow — accel-sim.out links successfully, 3,982,056 bytes. Before these three changes the build did not reach the link step.

Each change is compiled out on x86 / CUDA 12 by its own guard, so existing configurations take the identical code path; I have not separately rebuilt on x86 to confirm that.

Deliberately out of scope

src/accelwattch/mcpat.mk, mcpatXeonCore.mk and cacti/cacti.mk carry their own copies of the same SSE flags, and also hardcode g++ -m64 / -m32, which aarch64 GCC does not accept either. Porting that legacy make-based path is a larger job than removing two flags, and it is not the path the CMake build uses, so it is left alone here rather than half-fixed. It remains x86-only.

🤖 Generated with Claude Code