I’m saying that the specification is wrong. Your points about compilers having to optimize based on in-bounds are a statement about a sad and easily fixable reality and I am proposing to change that reality.
Conversation
No, you're misunderstanding / misinterpreting what I was saying. I was talking about a lot more than the GEP inbounds marker for pointer arithmetic. LLVM and GCC fundamentally treat pointers as more than addresses and objects as more than data laid out at an address in memory.
2
1
You can trivially make both compilers think that all pointers point into the same very large and diverse object.
1
Sure, and you lose a whole lot of the optimizations that make C efficient. Pointers and aliasing are huge blockers for optimization even with all the extensive leveraging of the aliasing / indexing guarantees which go a long way to making optimizations possible.
1
2
The most important optimizations still work in the C that I describe. I’ve tried variations. I think the only one that really hurts is strict aliasing. Without that you lose too much load elimination. But that one doesn’t produce full UB - it just creates extra load motion.
1
Type-based alias analysis (-fstrict-aliasing) is only a small portion of the overall alias analysis. The basic baseline alias analysis and reasoning about memory even without AA is extremely important for basic optimizations / code movement, and there's no switch for disabling.
2
1
You're saying that you want that all entirely disabled, with pointers treated as addresses. That's asking for a whole lot more than -fno-strict-aliasing and not marking pointer arithmetic inbounds (and the latter definitely has a huge impact on important loop optimizations, etc).
1
1
I'm certainly not saying that it can't be done or that it isn't useful but that you're understating how much needs to be changed and the impact of it. Memory corruption also doesn't become predictable, just *less* impacted by optimization. It's still always going to be impacted.
1
1
Here's something that's undefined: accessing uninitialized data.
int a; if (cond1) { a = 5; } else { if (cond2) { a = 10; } } use(a); do_other_stuff(); use(a);
Lets say that cond1 & cond2. Should both calls to use(a) be guaranteed to read the same value from uninitialized data?
2
1
2
i.e. it actually needs to assign a register to it, read a value, and potentially spill that to the stack so it can read it again later. LLVM won't currently do that. In rare cases this can have safety implications. A safe language would either force another else branch or zero.
2
It's still a safety issue if you make it into an unspecified value based on whatever happened to be in register or stack location, which varies based on choices in how the code is compiled. It becomes far more extreme if you're talking about memory safety far beyond uninit reads.