C compiler (over-)optimization (was: netbsd-11 gcc bug)
Edgar Fuß <[email protected]> Fri, 29 May 2026 19:12:51 +0200
| Newsgroups | gmane.os.netbsd.devel.toolchain |
|---|---|
| Message-ID | <[email protected]> |
> That is, after all, what compilers are for: to be useful. This makes me believe the problem is much simpler, worse, and lies deeper. The question is: useful for whom? One part of people programming in C, especially system programmers (for whom the language has originally been designed) obviously (or so I think) regard C as a kind of abstract portable assembler (which, as far as I understand, B and K&R C were sort of intended to be), are knowledgeble of assembly language(s) and read *p++ = q->foo_ch; as MOV.B 37(A5), (A6)+ Then, because C was so widely available (because it ws used to write OSes and without an OS, there would be no point in writing applications), application programmers started to use C to write, well, applications (I'm not talking of Unix userland, which was probably mostly written by system programmers). And they read above C code as abstract_assignement(source_type: abstract_char, destination_type: abstract_char, destination: abstract_pointer_dereference(p), source: abstract_struct_type_fetch(type: char, base: abstract_pointer_dereference(q), field: "ch")); abstract_pointer_increment(type: abstract_char, pointer: p); sequence_point; Parallel to that, two things happened to real computers: 1. sign-magnitude, one's complement, 6-bit-chars and 36-bit-words disappeared 2. SMP, out-of-order-execution, speculative execution etc. appeared And then, C, the gory details of which used to be de-facto-defined by the existing compiler(s), written by system programmers in a way the language was useful to them, was standarized (sill supporting 6-bit-one's-complement-chars and 36 bit longs), trying to abstractly define what was common sense for the sematics before. On top of that, compiler authors who weren't (or didn't care for) system programmers tried to make the language "useful" (e.g. 0.03% faster in edge cases) for application programmers, obeying the words of the standard. That can't work. I'm afraid the only way out would be to abandon C as a system programming language, invent a new one that, e.g., forbids optimizing away null pointer tests because 42 lines above, there's an expression that is formally UB if NULL is 0x12345678. Of course that's not going to happen.