That's a rookie mistake. After being wrong enough times, most people will catch on that the chances of a compiler bug are near enough to zero to not worry about. The last actual compiler bug I can remember was probably 30 years ago.

If we expand looking for a compiler bug to looking for a bug in dependencies, I still don't think that should be the first step of searching for a problem (unless your dependencies are that bad, which sometimes they are). However, it's not a bad thing to do. Sometimes, you will have bugs in your dependencies, so you should know how to debug them, so it's a skill you should practice. Also, any time spent debugging your dependencies is also time spent getting deep knowledge of your dependencies which is important to have. Anyway, what else are you going to do when you're stuck on a debugging task where it looks to you that the code is right, but the answer is wrong.

there is a telltale signature for compiler bugs:

1) your test suite works over several revisions of the compiler

2) after you upgrade, suddenly one test fails (especially if it's out of hundreds)

2a) you can isolate the minimum condition and it really leaves your head scratching

3) rewriting the code in a slightly different way makes it pass

The time I found a compiler bug it was because of an optimization that missed a corner case that I just happened to be using.

Or it was undefined behavior in your code, like depending on the evaluation order of function parameters, or one of mine, testing an array element before testing the index was within bound.

Broken: table[table_i].values[j] && j<category_map_count && to_i<category_array_len; Fixed: j<category_map_count && table[table_i].values[j] && to_i<category_array_len;

Optimizer: "j was used to access values array, j outside array would be undefined behavior, therefore it must have been within the array boundaries and does not need to be tested."

Oh, and threading bugs where some variable that should have been mutex locked or made atomic gets moved in or out of a register depending on the phase of the moon, causing other threads to fail to notice changes to that variable...but add a debug line and it suddenly works.

A wonderful example of this was some Linux kernel code that ended up causing a security vulnerability. It was something approximating:

  int foo(struct data *data) {
    struct member *member = &data->member;
    
    if (data == NULL) {
        return -EINVAL;
    }

    // Do stuff
  }

Assigning a value to member is just a matter of taking data and adding the value of member, so won't explode if data is NULL since it's not actually dereferencing that address. But this is still in undefined behaviour territory, so gcc assumed that we must know that data could never be NULL and optimised out the check.

This sort of thing is why I have definite feelings about the use of C in security sensitive contexts.

hahah good point. The bug I discovered was in the erlang compiler, which does not have UB (in the language being compiled), and threading bugs are either rarer or obvious.

Back in the day Red Hat decided to ship GCC 2.96 which was unstable and not meant for general release. I've seen a handful of compiler bugs but all (or almost all) of them can be traced back to that decision, but because that happened right when I started writing software full time it took a bit before I started trusting the compiler.