Hi!<div><br></div><div>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 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html</a> for details.</div>
<div><br></div><div>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:</div>
<div><br></div><div>* 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.</div>
<div>* 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).</div>
<div>* 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().</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks,</div><div>Richard</div>