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

Richard Smith richard at metafoo.co.uk
Thu May 9 12:11:39 PDT 2013


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().

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130509/15e4347b/attachment.html>


More information about the cfe-dev mailing list