Re: C compiler (over-)optimization (was: netbsd-11 gcc bug)
Mouse <[email protected]> Fri, 29 May 2026 14:21:18 -0400 (EDT)
| 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? Well, yes, that is an important addendum. At one point, "their vendors" would have been the obvious answer. But today the biggest two options are both open source, so, while that answer is still valid to an extent (modulo s/vendor/supplier/), it's a great deal fuzzier what the exact utility metric is. > 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), [...] > 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 [...] Yes. That matches my own understanding. > 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 Well, out-of-order and speculative execution are not all that relevant here. They don't affect the C abstract machine, not even today's C abstract machine. In theory, they don't even affect the machine-language abstract machine. SMP is a little more relevant, but not much. > 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. I don't think so. I think you/we just need two flavours of C compilers: ones for applications and ones for OS implementations (or possibly three, with the third one being for benchmarks). Formally-undefined behaviour is not a problem, after all, if you can count on having a compiler that turns it into what you actually want. A compiler can define, document, and support semantics for something that is formally UB, after all; that is entirely within the leeway the spec permits. What you really need is a compiler supplier that understands that usefulness is the true metric of goodness, as opposed to benchmarks or even strict spec conformance, that "but it conforms to the spec" is not an appropriate response to a bug report such as might have come out of the example that started this discussion. Well, understands that and considers the use cases you care about important enough to supply a compiler for. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B