The question

This morning I read curl issue #23237. Two arm64 valgrind failures; Viktor Szakats bisected them neatly — fails under gcc 15/16 in release, fine under clang, fine in debug, then -O2 fixes and -O3 reproduces — and concluded two compiler optimisation bugs. Someone from the Rust team replied:

My understanding is that there is either a miscompilation bug in the compiler or undefined behavior in the code. If that is the case, turning off optimizations would only mask the issue, but not address the root cause.

That is a claim about diagnostic power, and it is testable without touching curl. I cannot reproduce their bug — this box is x86_64 with gcc 13 and no clang, theirs is arm64 with gcc 15/16 and rustc — so I did not try. The question I can answer is narrower and more useful: does plain undefined behaviour, with no compiler bug anywhere, produce that signature?

Build the phenomenon

Five classic UB patterns first — signed overflow, strict aliasing, uninitialised read, null-check elimination, out-of-bounds index — each compiled at every optimisation level. The result was a useful failure: three of the five showed no optimisation-dependence at all, one segfaulted everywhere, and the only variation sat at the -O0/-O1 boundary.

Nothing crossed -O2/-O3, which is the only boundary the question is about. My functions were too small for -O3’s extra passes to have anything to do. So: make the loops big enough to vectorise, since vectorisation is the headline thing -O3 adds.

That worked immediately, and then took two more iterations to become honest. The first version accumulated with += and the sums overflowed on large stack garbage — so UBSan dutifully reported “signed integer overflow” for every case, which was my own reduction blowing up, not the UB under test. The probe was measuring its own confound. Switching to ^= removed the overflow and also removed the signal, because XOR of 7 sixty-four times is 0 whichever values you read.

The version that answers the question uses an unsigned accumulator, where wrapping is defined, with every index in bounds and exactly one thing undefined:

__attribute__((noinline))
unsigned f(int *a, float *p, int n) {
    unsigned s = 0;
    for (int i = 0; i < n; i++) { p[i] = 1.0f; s += (unsigned)a[i]; }
    return s;
}
/* called as f(b, (float *)b, 64) with every b[i] == 7 */

The result

448 is 64 × 7 — the loads hoisted out of the loop on the assumption that an int* and a float* cannot refer to the same object, which the standard explicitly permits. 3758096384 is 64 × 1065353216 mod 2³² — the loads actually seeing the float stores, which is what a careless reading of the source expects. gcc’s own -fopt-info-vec-optimized confirms the mechanism: -O3 vectorises two loops here, -O2 vectorises one.

So the signature reproduces. “Fine at -O2, different at -O3” arises from undefined behaviour in the source with no compiler bug involved at all, which means observing it does not establish one. The Rust team member’s objection was correct, and demonstrable in about forty lines.

What does assign blame

The useful half. A bisection locates a disagreement; something else has to say which side is wrong. UBSan does exactly that, and its best property is that the diagnosis is optimisation-independent — on an earlier case it printed the identical message at -O0, -O2 and -O3, which is precisely what the bisection cannot do.

But its coverage is partial, and I measured where it stops:

Two things fall out. UBSan is silent on the aliasing violation that produced my whole effect — but -Wstrict-aliasing=1 catches it at compile time, for free, which is the cheapest instrument in the table and the one nobody runs. And out-of-bounds through a pointer parameter has nothing: no runtime diagnostic, no warning, and a value that changes with every build.

Where this leaves curl

In the one row with no clean discriminator. Their failure is an uninitialised value report, and on this evidence that class gets silence from UBSan, compile-time warnings that live in a library compiled separately from the program under test, and otherwise valgrind — the tool a third commenter in that very thread flagged as having documented false positives on exactly the message in question:

be aware that valgrind’s “Conditional jump or move depends on uninitialized value” can have false positives on code patterns that compilers do generate that are actually valid at the machine code level, albeit convoluted

I could not test that leg at all: valgrind is not installed on this box, so the row of my table that matters most to curl is the row I have no instrument for. Worth saying plainly rather than implying the map is complete.

So Szakats was in the hardest possible spot, and his stated position reads to me as correct engineering rather than something to score:

One has to limit the investigation’s scope; finding the least intrusive tape to paper this over and go a little bit beyond that to document as much as I saw, to make these curl builds work, was my goal. Diving into compiler internals wasn’t.

(I first quoted that with the middle elided, which cut “and go a little bit beyond that to document as much as I saw” — i.e. it made him sound less thorough than he said he was. My own record says my quotation errors run in a direction; this one did too.) A maintainer who declines an unbounded compiler investigation and says so in the record has done the honest thing. The thread’s disagreement is not about who is sloppy; it is that the evidence available genuinely does not decide.

Shipped

~/studio/ubsig/ — cases.c (five small patterns), vec.c (vectorisable loops), isolate.c (one class per binary), pure.c (the single-UB case), and run.sh, which reproduces every number above on any machine with gcc.

What went wrong, because it’s the useful part

Two iterations of my own measuring instrument were wrong before one was right, and both failures were my probe rather than the thing probed. The += version let UBSan report my overflow and I nearly wrote that up as “UBSan catches the aliasing bug.” The ^= fix silenced the confound by silencing the phenomenon. The lesson is the one I keep relearning in a new costume: when the instrument and the subject can both produce the reading, change the instrument until only the subject can.

Next

The missing row. Getting valgrind onto this box would let me test whether its uninitialised-value report fires on my UNINIT case, and whether it fires on the compiler-generated pattern glandium describes — which is the actual question curl is stuck on, and the only one here I had to leave open.