GCC removes a bounds check in the right operand of &&, but not in the left operand, why?

Accessing an array out of bounds is undefined behavior so the compiler can assume that it never happens in the LHS of the && expression. It is then jumping through hoops (optimizations) to notice that since ARRAY_LENGTH is the length of the array, the RHS condition must necessarily hold true (otherwise UB would ensue in the LHS). Hence the result you see.

The correct check would be idx < ARRAY_LENGTH && g_ptrArray[idx] != nullptr.

Even potential undefined behavior can do nasty things like that!

The C standard (C17 6.5.6 §8) says that we may not do pointer arithmetic outside an array nor access it beyond the array – doing so is undefined behavior and anything can happen.

Therefore, strictly speaking, the array out of bounds check is superfluous since your loop condition goes as "stop upon spotting a null pointer within the array". And in case g_ptrArray[ idx ] is an out of bounds access, you invoke undefined behavior so the program would in theory be toasted at this point. So there’s no need to evaluate the right operand of &&. (As you probably know, && has strict left-to-right evaluation.) The compiler can assume that the access is always inside the array of known size.

We can smack the compiler back in line by adding something that makes it impossible for the compiler to predict the code:

int** I_might_change_at_any_time = g_ptrArray;
void test2()
{
    unsigned int idx = 0;
     

    // check for idx value is NOT present in code
    while( I_might_change_at_any_time[ idx ] != nullptr && idx < ARRAY_LENGTH)
    {
        g_sum += *g_ptrArray[ idx ];
        ++idx;
    }
}

Here the pointer acts as "middle man". It’s a file scope variable with external linkage and so it may change at any time. The compiler can no longer assume that it always points at g_ptrArray. It will now be possible for the left operand of && to be a well-defined access. And therefore gcc now adds the out of bounds check to the assembler:

        cmp     QWORD PTR [rdx+rax*8], 0
        je      .L6
        cmp     eax, 666
        je      .L6

The explanation: as documented by Marco Bonelli, the compiler assumes that the programmer who wrote the first test g_ptrArray[idx] != nullptr knows that this code has defined behavior, hence it assumes that idx is in the proper range, ie: idx < ARRAY_LENGTH. It follows that the next test && idx < ARRAY_LENGTH is redundant has idx is already known to be < ARRAY_LENGTH, hence the code can be elided.

It is unclear where this range analysis occurs and whether the compiler could also warn the programmer about a redundant test elided, the way it flags potential programming errors in if (a = b) ... or a = b << 1 + 2;

What makes this optimisation perverse IMHO is the lack of a warning for a non obvious optimisation.

Unlike compilers, programmers are human and make mistakes. Even 10x programmers sometimes make stupid mistakes, and compilers should not assume that programmers are always right, unless they explicitly boast about it as in if ((a = b)) ...

The incorrect order of the tests g_ptrArray[idx] != nullptr and idx < ARRAY_LENGTH should be obvious in a code review. Conversely, the fact that idx < ARRAY_LENGTH is redundant if g_ptrArray[idx] != nullptr is assumed to be legitimate is non obvious to human readers of the code. The compiler assumes that the programmer knows that g_ptrArray[idx] != nullptr can be performed, hence assumes that idx is in the proper range and deduces that the second test is redundant. This is perverse: if the programmer was shrewd enough to correctly assume idx is always in the proper range, they surely would not have written the redundant test. Conversely, if they made a mistake and wrote the test in the wrong order, flagging the redundant code as such would help fix a blatant bug.

When compilers become smart enough to detect such redundancy, this level of analysis should profit the programmer, and help detect programming errors, not make debugging harder than it already is.

In the language the Dennis Ritchie invented in the early 1970s and documented in the 1974 C Language Reference Manual, an expression like arr[index] would take the address of arr, use the platform’s natural pointer indexing method to displace it by the size of i elements of arr‘s element type, and access the resulting storage using the platform’s natural means of reading an object of that type, with whatever consequences would result. If the address would fall outside the array, but the programmer knew enough about how arr would be placed and the way the platform would respond to reads of that address to know that the behavior of reading an address would satisfy application requirements, then code which read outside the array would be non-portable but possibly correct. On the flip side, if on the target platform, attempting to read from a certain address within the a second of the last floppy disk access would cause the most recently accessed track on that disk to be completely overwritten (actual behavior of the popular Apple II computer) and a programmer didn’t ensure that no stray reads would hit such addresses, such code should have been viewed as broken. There was no need for a compiler to distinguish between correct but not portable code and broken code.

The C Standard allows implementations to process array accesses in a manner consistent with Dennis Ritchie’s language, but it makes no attempt to catalog all of the actions that should be usable within non-portable programs for various platforms. Instead, it waives jurisdiction over how implementations process actions such as array indexing beyond the immediate confines of an array, using the phrase "Undefined Behavior" as a catch-all for both constructs that are non-portable but may be correct on some implementations, to those that are simply erroneous, without making any effort to distinguish them.

The authors of clang and gcc operate under the philosophy that when the Standard says a construct or corner case is "non-portable or erroneous", what it really means is "non-portable, and therefore erroneous", and that because the authors of the Standard don’t care how implementations treat such constructs or corner cases, programmers have no right to view any way the implementation might handle such cases as being inferior to any other.

Incidentally, the loop may have been written in such a weird fashion because the original compiler it targeted would process that loop slightly more efficiently than a version which checks the boundary condition first. Such optimizations tend to be futile when using the clang and gcc optimizers even when UB isn’t an issue, because those implementations will substitute their own judgment of how the loop should be processed for what the programmer wrote, even if what the programmer wrote would have been more efficient.