search for: receive_ptr

Thanks Mark! That'd be a useful starting point. For the rest of the people here: to be a bit more specific, I am having doubts about the following: - Can later optimization passes or code generation still create machine code that takes and stores (in a register perhaps) an address of something on the stack, even if not semantically visible to the programmer? Can this somehow be detected?

On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote: > I assume by “drop support”, you mean reject it in the bitcode reader/IR > parser? We can’t reasonably support a complex feature like inalloca if > nobody is testing it. If we can’t reasonably upgrade it, and we don’t think > there are any users other than clang targeting 32-bit Windows, probably

...ld interact, so it might be worth planning out. > I do recall that MSVC does some pretty squirrelly stuff when you insert `alloca` calls into a call sequence. In this example, arguments are evaluated in the order 2, 3, 1: struct Foo { Foo(); Foo(const Foo &o); ~Foo(); int x; }; void receive_ptr(Foo, void *, Foo); extern "C" void *_alloca(size_t n); extern int gv; void f(int n) { receive_ptr(Foo(), _alloca((++gv, n)), Foo()); } The standard says order of argument evaluation is unspecified, so this ordering is valid. However, I wouldn't want to implement the same behavior in...