Re: C compiler (over-)optimization (was: netbsd-11 gcc bug)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B