There are a lot of instructions on x86 that leave the flag(s) in an indeterminate state, which means the whole FLAGS register is also undefined. Most will have AF undefined, for example
The OF and CF flags are set to 0. The SF, ZF, and PF flags are set according to the result (see the “Operation” section above). The state of the AF flag is undefined.
but there are also other instructions that leave other undefined flags like
AAS: OF, SF, ZF, PF
DAS : OF
SAL/SAR/SHL/SHR: OF, AF, CF
IMUL: SF, ZF, AF, PF
IDIV: CF, OF, SF, ZF, AF, PF
The x87 FPU also has its own flags which may also be left unspecified after many operations
You can open any of the lists in the X86 Opcode and Instruction Reference like this one and look at the
undef_f column to have a summary of undefined flags after each instruction
Normal registers can also have an unspecified state, too. Early x86 CPUs will leave the high bit of a
mov Reg, Sreg undefined
MOV Reg, Sreg, the processor copies the content of Sreg to the 16 least significant bits of the general-purpose register. The upper bits of the destination register are zero for most IA-32 processors (Pentium Pro processors and later) and all Intel 64 processors, with the exception that bits 31:16 are undefined for Intel Quark X1000 processors, Pentium and earlier processors.
https://www.felixcloutier.com/x86/mov.html (emphasis mine)
SHRD still have undefined result
If the count operand is CL, the shift count is the logical AND of CL and a count mask. In non-64-bit modes and default 64-bit mode; only bits 0 through 4 of the count are used. This masks the count to a value between 0 and 31. If a count is greater than the operand size, the result is undefined.
Some other examples on x86
LAR: The following fields are returned only if the operand size is greater than 16 bits: Bits 19:16 are undefined
SMSW: In non-64-bit modes, when the destination operand is a 32-bit register, the low-order 16 bits of register CR0 are copied into the low-order 16 bits of the register and the high-order 16 bits are undefined
TZCNT: if source operand is zero, the content of destination operand are undefined
SLDT: The high-order 16 bits of the register [...] are undefined for Pentium, Intel486, and Intel386 processors
Not sure whether their intermediate results can be utilize for other purposes or not though
Division and multiplication also often leave unspecified results
For example on PowerPC we have
For the case of
-2**31 / -1, and all other cases that cause overflow, the content of GPR RT is undefined.
If an attempt is made to perform the divisions 0x8000_0000_0000_0000 / -1 or / 0, the contents of RT are undefined
Similarly on MIPS
If the divisor in GPR rt is zero, the arithmetic result value is UNPREDICTABLE
In older MIPS ISAs there are also restrictions regarding the HI and LO registers
In MIPS 1 through MIPS III, if either of the two instructions preceding the divide is an MFHI or MFLO, the result of the MFHI or MFLO is UNPREDICTABLE
On MIPS many floating-point instructions also leave unpredictable result in the registers, like
The fields fs, ft, and fd must specify FPRs valid for operands of type fmt. If the fields are not valid, the result is UNPREDICABLE.
The operands must be values in format fmt; if they are not, the result is UNPREDICTABLE and the value of the operand FPRs becomes UNPREDICTABLE.
The fields fs and fd must specify valid FPRs: fs for type fmt and fd for long fixed point. If the fields are not valid, the result is UNPREDICTABLE.
The operand must be a value in format fmt; if it is not, the result is UNPREDICTABLE and the value of the operand FPR becomes UNPREDICTABLE.
The result of this instruction is UNPREDICTABLE if the processor is executing in the FR=0 32-bit FPU register model; it is predictable if executing on a 64-bit FPU in the FR=1 mode, but not with FR=0, and not on a 32-bit FPU.