[cfe-dev] [RFC] Approach for C++1y N3639 (runtime-sized arrays with automatic storage duration)

[Richard Smith]

On Thu, May 9, 2013 at 1:24 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Thu, May 9, 2013 at 12:11 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > Hi!
> >
> > C++1y adds support for arrays of runtime bound (ARBs) to the C++
> language.
> > These are basically a restricted form of VLA, which can only be used for
> > stack variables, and to which sizeof/decltype/typedef/etc can't be
> applied
> > (though we'll still support those constructs as a GNU extension). See
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html for
> > details.
> >
> > Under N3639, we are required to throw an exception if the array bound *
> > sizeof(element) calculation overflows, or if the array bound is too
> small.
> > We're also permitted to call the global operator new/operator delete to
> > acquire storage for the array, if we so choose. VLA stack usage can be
> > problematic in some circumstances (especially in heavily-threaded code),
> so
> > this may be something we want to pursue. Therefore I'm proposing the
> > following implementation approach:
> >
> > * Add a -farb-stack-limit=N command-line option to control the maximum
> stack
> > memory which can be used by an ARB. If the ARB doesn't fit in this
> limit, we
> > use heap allocation instead. By default, there is no limit.
> > * Add a -farb-heap-limit=N command-line option to control the maximum
> heap
> > memory which can be used by an ARB. If the ARB doesn't fit in this
> limit, we
> > call __cxa_throw_bad_array_length. By default, the limit is 0 (never use
> > heap allocation).
>
> What's the particular motivation for the heap limit option (when other
> explicit heap allocation has no such limit (neither at the language
> nor library level (things like std::vector, etc))?


Perhaps it would make more sense here to just have a flag to say whether we
will ever use heap allocation as a fallback. I can certainly imagine
situations where you want a stack limit but never want to fall back to the
heap (and equally, a stack limit and a heap fallback seems very useful).

> * If the bound is erroneous (too small, multiplication overflows, beyond
> our
> > limit), we call __cxa_throw_bad_array_length. To support old C++ ABI
> > libraries, we emit a weak form of this in every TU which invokes it, and
> the
> > weak form calls __builtin_trap().
> >
> > Does this seem reasonable? Would we want any part of this checking (for
> > instance, the overflow check + trap) in C, or in C++-before-C++14? Maybe
> the
> > flags should be -fvla-foo instead of -farb-foo?
> >
> > Thanks,
> > Richard
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130509/4446599c/attachment.html>