This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thu, 13 Jun 2013, Ed Smith-Rowland wrote:
On 06/10/2013 02:08 PM, Ulrich Drepper wrote:So it looks like compiler magic it is. Is the always_inline trick still a possibility?)On Mon, Jun 10, 2013 at 11:45 AM, Marc Glisse <marc.glisse@inria.fr> wrote:void f(int n, void *p=alloca(n));Before anyone uses this as an example, it is really wrong to use alloca inside a parameter list. The alloca allocation might interfere with pushing parameters on the stack for function calls. This was at least true for older compilers but I think it's still a valid concern.
No, always_inline isn't possible either (or at least not alone). With copy elision, we may end up constructing an object declared several frames above, so we need either a way to detect if copy elision is being done on this object (and not use the stack in that case) or a way to forbid copy elision on this object. The first option seems better that the second.
Also, I think I would like our implementation to fail over to heap allocation if the size request is too large for a stack frame.Finding a meaningful upper limit of stack frame size might be a trick.
I think 2048 bytes is a good start as a switch point between stack and heap ;-)
Since we will use compiler magic, it should be possible to avoid a linear growth in:
for(...){ dyn_array a(100); } (alloca would probably have issues with that). -- Marc Glisse
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |