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

[Chandler Carruth]

On Thu, May 9, 2013 at 9: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).
> * 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().
>

I really like the ability to automatically defer large allocations to the
heap. I don't have any specific problems with your proposed interface or
semantics, but I would really like to work with the GCC community to get
agreement on the semantics and flag names here (the library routines and
exception names should I suspect be handled via the ABI group). Too often
we've have divergence between the two and had to paper over it with
compatibility layers (-fcolor-diagnostics vs. -fdiagnostics-color ...).


> 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?
>

I think it would be very useful to allow (as an extension) applying these
semantics to VLAs in other language modes. It would suggest:

1) It be clearly marked as an extension with flags to control it. I'm OK
with default-on, but I suspect the better strategy is to make this opt-in.

2) I think opting into it should get you the *full* semantic model
proposed: the crazy things you can do with VLAs that didn't make it into
C++1y should become errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130509/af5aafb2/attachment.html>