4 ms·
Y is never visible from foo()s scope. You'd have to employ ABI specific stack manipulation to get to it. Optimization in the outside frame doesn't depend on foo
by kevin_thibedeau 3y ago
Y is never visible from foo()s scope. You'd have to employ ABI specific stack manipulation to get to it. Optimization in the outside frame doesn't depend on foo().
- tyler569 3y agoAnd that ABI specific stack manipulation would be UB, so the optimizer can assume it doesn't happen. With no UB, that's not true.
- Dylan16807 3y agoYou assume a langue without UB would allow stack manipulation. But then it would have to be defined. How would you possibly define it fully?
- remexre 3y agoThere's an area of memory into which variables with automatic storage duration are allocated at implementation-defined addrs, at any point exactly those variables have addresses.
- Dylan16807 3y ago> at any point exactly those variables have addresses That doesn't sound like it lets me increment any stack address I want and store into the resulting pointer. And are return values still on the same stack? I probably should have said I meant the traditional kind of C stack.
- remexre 3y ago> That doesn't sound like it lets me increment any stack address I want and store into the resulting pointer. Why not? > And are return values still on the same stack? Other implementation-defined things might have addresses too, those things just aren't variables. I think you might be able to still allow inlining without UB if you make it implementation-defined per call-site what other things might get addresses.
- Dylan16807 3y ago> Why not? At this point the conversation has completely converged so I'm only going to reply over here: https://news.ycombinator.com/item?id=36169808 https://news.ycombinator.com/item?id=36169808