Specification Update

Errata
Specification Update 83
W123. IRET under Certain Conditions May Cause an Unexpected
Alignment Check Exception
Problem: In IA-32e mode, it is possible to get an Alignment Check Exception (#AC)
on the IRET instruction even though alignment checks were disabled at
the start of the IRET. This can only occur if the IRET instruction is
returning from CPL3 code to CPL3 code. IRETs from CPL0/1/2 are not
affected. This erratum can occur if the EFLAGS value on the stack has
the AC flag set, and the interrupt handler's stack is misaligned. In IA-
32e mode, RSP is aligned to a 16-byte boundary before pushing the
stack frame.
Implication: In IA-32e mode, under the conditions given above, an IRET can get a
#AC even if alignment checks are disabled at the start of the IRET. This
erratum can only be observed with a software generated stack frame.
Workaround: Software should not generate misaligned stack frames for use with IRET.
Status: For the steppings affected, see the Summary Tables of Changes.
W124. Performance Monitoring Event FP_ASSIST May Not Be
Accurate
Problem: Performance monitoring event FP_ASSIST (11H) may be inaccurate as
assist events will be counted twice per actual assist in the following
specific cases:
• FADD and FMUL instructions with a NaN(Not a Number) operand and a memory
operand
• FDIV instruction with zero operand value in memory
In addition, an assist event may be counted when DAZ (Denormals-Are-Zeros) and
FTZ (Flush-To-Zero) flags are turned on even though no actual assist occurs.
Implication: The counter value for the performance monitoring event FP_ASSIST
(11H) may be larger than expected. The size of the error is dependent
on the number of occurrences of the above conditions while the event
is active.
Workaround: None identified.
Status: For the steppings affected, see the Summary Tables of Changes.