Let's break down exactly what's going on here, and how to write a compliant, optimization-safe solution that fits CS:APP's constraints.

The Root Cause: Undefined Behavior Triggers Aggressive Optimizations #

Your core problem is that 1 << 31 is undefined behavior in C for 32-bit signed int types. The C standard states that shifting a signed integer such that the result falls outside the type's representable range (which 1 << 31 does for a 32-bit int, since it produces Tmin, the minimum signed value) is not defined.

When GCC optimizes (with -O1, -O2, etc.), it leans hard into the standard: it assumes undefined behavior never happens, so it can rewrite code that relies on it in unexpected ways. In your case, the compiler likely treats 1 << 31 as an invalid expression, and optimizes the entire !((x + 1) ^ (1 << 31)) check to always return 0—since it doesn't recognize 1 << 31 as a valid Tmin value.

On top of that, your original implementation has a hidden edge case waiting to bite you: if x = -1 (0xffffffff), x + 1 becomes 0, and 0 ^ Tmin is non-zero, so !check returns 0 (which is correct here), but the undefined behavior of 1 << 31 is still a showstopper for optimizations.

A Correct, Optimization-Safe Implementation (Fits CS:APP Rules) #

We need to implement isTmax() using only allowed operators, and avoid any undefined behavior. Remember the key properties of Tmax (0x7fffffff):

• Tmax + 1 = Tmin (0x80000000)
• Tmax ^ Tmin = 0xffffffff (all bits set, which is -1 in two's complement)
• We need to exclude x = -1, since -1 + 1 = 0, and -1 ^ 0 = 0xffffffff (also -1)—so we need to distinguish these two cases.

Here's a compliant solution that works at any optimization level:

int isTmax(int x) {
    // y will be Tmin if x is Tmax, 0 if x is -1
    int y = x + 1;
    // Check if x ^ y is all 1s (-1), AND x is not -1 (!!y ensures y != 0)
    return !( (x ^ y) + 1 ) & !!y;
}

Let's walk through the logic:

1. For x = Tmax: y = Tmin, x ^ y = 0xffffffff (-1), (x^y)+1 = 0, !0 = 1; !!y = !!Tmin = 1; so 1 & 1 = 1 (correct).
2. For x = -1: y = 0, x ^ y = 0xffffffff (-1), (x^y)+1 = 0, !0 =1; but !!y = !!0 =0; so 1 &0=0 (correct).
3. For any other x: x^y won't be -1, so (x^y)+1 won't be 0, ! gives 0, so the result is 0 (correct).

This uses only allowed operators (count them: +, ^, +, !, !, &—total 6, well under the 10 limit), no undefined behavior, and passes all CS:APP test cases regardless of optimization settings.

Why volatile "Fixes" It (But Isn't a Real Solution) #

Marking check as volatile forces the compiler to avoid optimizing that variable—it has to compute and store its actual value, bypassing the aggressive optimizations that break the undefined 1<<31 case. But this is a band-aid, not a fix: you're still relying on undefined behavior, which could break in other compilers or future GCC versions.

Final Notes #

CS:APP's bitwise programming problems are designed to teach you to work within the constraints of two's complement arithmetic and avoid undefined behavior. Directly trying to create Tmin with 1<<31 is a trap—instead, derive everything from the input x and its inherent properties.

内容的提问来源于stack exchange，提问作者Marko Sagadin