Pointers Are Complicated II, or: We need better language specs

Post by lmm » Tue, Dec 15, 2020, 6:14 AM UTC

mehrdadn wrote: post #80

lmm wrote: post #79

Earlier quoted context omitted.

> Just because two pointers point to the same memory location, it does not mean they have an identical representation as an integer. Yes, I know. That's irrelevant here for two reasons: firstly, the pointers might compare equal (which is all that matters for this argument), and secondly, once again, the comparison isn't being made between pointers , the comparison is being made between integers. > The entire page is…

> Yes, I know. That's irrelevant here for two reasons: firstly, the pointers might compare equal (which is all that matters for this argument), and secondly, once again, the comparison isn't being made between pointers, the comparison is being made between integers. You know what, I think you're right, at least on the second point. I guess the code isn't UB after all then. Somehow I kept reading it as if it's compari…

Post by Dylan16807 » Tue, Dec 15, 2020, 6:51 AM UTC

SAI_Peregrinus wrote: post #67

anderskaseorg wrote: post #54

Earlier quoted context omitted.

If the programmer really needs reads and writes through particular pointers to happen in a particular sequence, because the target memory follows different rules than the language ordinarily allows the compiler to assume, then it’s the programmer’s responsibility to use the annotation provided by the language for exactly that purpose: volatile. If the compiler had to assume that every pointer needs to be treated as v…

To be extra pedantic, that's not what volatile does. Volatile ensures that access through the variable must behave strictly according to the rules of the C abstract machine, but the definition of access is implementation defined . A compiler author could define "access" to be "reads from the variable" or "writes to the variable", or neither, and make the entire keyword useless. As long as they document that somewhere…

Post by Dylan16807 » Tue, Dec 15, 2020, 7:10 AM UTC

mhh__ wrote: post #82

Dylan16807 wrote: post #47

Earlier quoted context omitted.

Not sure why you wanted to spend the time to prove "correct optimizations can be combined", but I take issue with that proof. It only works for optimizations that give code exactly the same behavior, which is severely limiting.

Exactly the same as in the as-is rule or optimisations explicitly allowed by the standard?

Post by aliceryhl » Tue, Dec 15, 2020, 7:13 AM UTC

mjevans wrote: post #65

klodolph wrote: post #23

Earlier quoted context omitted.

I've heard this proposal thrown around a lot on HN, but how would that even work? Can you describe how the compiler would do this, what patterns it would look for, and what error messages it would produce? For example, consider this: int factorial(int n) { int r = 1; for (int i = 1; i Since there are two instances of possible UB in the above function, what error messages would you like the compiler to produce? First…

What I want is for the compiler to have a mode (which ideally would be enabled by default, at least with modern compile targets) that never optimizes based on undefined behavior. It would do this by handing any UB as an error and making the programmer write a correct program that lacks UB through informing the programmer where undefined behavior has been proven by the compiler. This would improve both the code and th…

Post by Dylan16807 » Tue, Dec 15, 2020, 7:53 AM UTC

thaumasiotes wrote: post #88

Dylan16807 wrote: post #86

Earlier quoted context omitted.

I count the definitions given for a proof as part of the proof.

That is a serious mistake here, where the definition of a correct optimization is of significantly more interest than the result that they can be composed. We want to apply optimizations alone even more than we want to apply them together. Putting things another way, this definition is clearly not given as part of a proof; it is given for its own sake, and the proof uses it.