Instruction
INCSSPQ
Pops and discards the number of 8-byte shadow-stack entries given in the low byte of a register, as unwinding the stack needs; CET.
- Extensions
- Forms
- 1 (1 Legacy)
- Data
- Intel XED v2026.08.23
INCSSPQ drops entries from the shadow stack without checking them: it
adds eight times the unsigned number in bits 7:0 of its register to SSP,
the shadow-stack pointer. A RET pops one entry and compares it with the
return address on the normal stack; INCSSPQ is for frames that are left
without a RET. When longjmp or a C++ exception skips several frames,
their return addresses stay on the shadow stack, and the next RET would
meet the wrong one and raise #CP. The unwinding
page shows how glibc and libgcc count
the frames they skip and pop them with this instruction.
Eight bits of count
At most 255 entries go per instruction, and the upper bits of the
register are ignored, not saturated: a count of 256 pops nothing. With
-mshstk, GCC 14 and Clang 23 at -O2 compile _inc_ssp(n), whose
argument is an unsigned int, to a zero-extension (mov edi, edi in
GCC, mov eax, edi in Clang) and incsspq, so a larger count needs a
loop. Clang 23 also has _incsspq, which takes 64 bits; GCC 14 has only
_inc_ssp. INCSSPD, without REX.W, steps by the
4-byte entries of 32-bit code.
It touches both ends
Before it moves SSP, INCSSPQ reads the first and the last entry it pops, as shadow-stack loads, and discards them. A load from a page that is not a shadow-stack page raises #PF, so a count that would carry SSP past the end of the stack into a guard page faults instead. Since 255 entries span 2,040 bytes, less than a 4-KiB page, those two reads reach every page the range touches. A count of 0 still reads the top entry (twice, in AMD’s manual) and leaves SSP alone.
Where it runs
Unlike RDSSPQ, INCSSPQ is no NOP: without shadow stacks
enabled at the current privilege level (CR4.CET, and SH_STK_EN in
IA32_U_CET at CPL 3 or IA32_S_CET below) it raises #UD. A routine that
may run in either kind of thread can test RDSSPQ’s result first. On
Linux, shadow stacks are enabled per thread with
arch_prctl(ARCH_SHSTK_ENABLE), usually by the dynamic loader or the
static runtime, and new threads inherit the setting.
AMD’s Zen 5 guide lists INCSSP among the shadow-stack instructions Zen 5 supports, as microcoded. The KVM guest that ran the probe reported no shadow stacks in CPUID (leaf 07H, ECX bit 7), and both recorded cases raised #UD.
Forms
| Instruction | Encoding | Requires |
|---|---|---|
INCSSPQ r64 64-bit mode only
INCSSPQ_GPR64u8 | F3 REX.W 0F AE /5 | CET |
Operation
What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.
if not cr4 >> 23 & 1: # CR4.CET; clear without CET
fault(UD)
cet = u_cet if CPL == 3 else s_cet
if not cet & 1: # SH_STK_EN: shadow stacks off
fault(UD)
n = src.read() & 0xFF # bits 7:0, unsigned: 0 to 255
ss_load(ssp, 64) # the first element and the last
if n > 0: # of those it pops are read, and
ss_load(ssp + 8 * (n - 1), 64)
# dropped: a pop past the stack's
# end raises #PF there
ssp = ssp + 8 * n # 8-byte elements
# AMD's manual reads the element at SSP twice where n is 0, to the
# same effectRun on AMD Zen 5 (EPYC 9645): 2 cases. Its cases ran where CPUID reported no CET, and every one raised an exception.
Operands
| Operand | Kind | Action |
|---|---|---|
INCSSPQ r64 64-bit mode only | ||
r64 | explicit | read |
SSP | implicit | read, write |
Flags
None: XED records no flag that the forms test or change.
Attributes
What else XED records about the forms. How to read.
- All forms
- not in real-address mode
Intrinsics
The C intrinsics of Clang 23.1.2 that compile to INCSSPQ, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.
| Intrinsic | Compiles to |
|---|---|
_inc_ssp
void _inc_ssp(unsigned int __a) |
|
_incsspq
void _incsspq(unsigned long long __a) |
|
CPUID and processors
Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.
| ISA set | CPUID | Processors |
|---|---|---|
CET | CET | Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Sierra Forest, Clearwater Forest, Zen 3, Zen 4, Zen 5, Zen 6 Note: Zen 3 to Zen 6 have the shadow stacks of CET but not its indirect branch tracking, so ENDBR32 and ENDBR64 run on them as hint NOPs. AMD's references for Zen 3, Zen 4 and Zen 5 (55898, 55901, 57238) set CPUID_Fn00000007_ECX_x00[CET_SS] (bit 7) and leave bit 20 of CPUID_Fn00000007_EDX_x00, which Intel gives to indirect branch tracking, reserved and clear. Note: Zen 6 is listed because Zen 5 has these instructions. GCC's -march sets, which give the other features of Zen 6, leave them out, and AMD has not yet published a Processor Programming Reference for Zen 6. |
More CET instructions
Sources
- Intel XED v2026.08.23 (commit
0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model. - The CPU data of x86-64.net: Zen 3 to Zen 6, from GCC’s
-marchfeature sets and AMD’s Processor Programming References, which the page of each processor cites. - Clang's x86 intrinsic headers, LLVM 23.1.2 (commit
85ac56026243): the intrinsics, their signatures and doc comments, and the Clang of that release, which compiled each of them. - Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2 (325383-093, September 2026): Volume 2A, page 3-459 (INCSSPD/
INCSSPQ) - Linux kernel documentation: Control-flow Enforcement Technology (CET) Shadow Stack
- Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1 (253665-093, September 2026)
- AMD64 Architecture Programmer's Manual, Volume 3: General-Purpose and System Instructions (24594, rev. 3.36, March 2024), Wayback Machine copy of AMD's PDF
- Software Optimization Guide for the AMD Zen5 Microarchitecture (58455, rev. 1.00, August 2024), Wayback Machine copy of AMD's ZIP
The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The intrinsics and their signatures come from Clang, part of the LLVM Project, licensed under the Apache License 2.0 with LLVM Exceptions. The text is our own.