https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #2 from sagebar at web dot de --- (In reply to Andrew Pinski from comment #1) > The big question comes, where should the VLA type be finalized, at the use > or at the beginning of the statement. > > Statement expressions create a new statement so you are seeing that. > > I don't know the correct answer. Since VLA types are not part of the C++ > standard, what GCC does currently might be considered the correct answer > (and most likely could not be implemented different either). That may be so, however I find it extremely disconcerting that it is possible to have the contents of a compile-time dead branch be able to affect the generated assembly in ways that can cause some very real side-effects (function calls) at runtime. When I write a macro like `#define ifelse(c, tt, ff) ((c) ? (tt) : (ff))`, then I really _have_ to be able to rely on the fact that whatever happens, and whatever it is passed, _only_ 1 of `tt` or `ff` get evaluated at runtime, no matter what happens between me invoking g++, and eventually running the produced binary. To answer the question as to when finalization of the type should happen: the naive (and probably most comprehensible) answer would be at the end of the dead ?-branch, though I can see how that might be difficult since that branch doesn't have its own scope. I sadly don't know enough of how gcc in particular generates assembly, however I do know how a generic compiler works, so one solution might be to compile `0 ? vla-expr : other-expr' as `jmp 1f; vla-expr; jmp 2f; 1: other-expr; 2:` and use peephole optimization to transform this into `other-expr;`
