On Tue, Jan 26, 2016 at 08:58:06PM -0700, Martin Sebor wrote: > On 01/26/2016 04:02 PM, Marek Polacek wrote: > >The (invalid) testcase was causing an ICE because we were passing the result > >of array_type_nelts_top immediately into tree_int_cst_lt, but for VLAs, the > >result doesn't have to be a constant. Fixed by evaluating the bound of the > >array so that we're able to give a proper out-of-bounds diagnostics. And the > >VERIFY_CONSTANT should ensure that if the array bound couldn't be reduced to > >a constant, we bail out rather than evoke an ICE. > > Wow, you are quick! :) > > I wonder if it might be better to instead reject VLAs in constexpr > functions altogether. Not because they're not in C++, but because > C (or gcc) doesn't allow them to be initialized (and so accepting > an initialized VLA is a g++ extension of an extension), and > because in constexpr functions they are rejected without > initialization just like other uninitialized variables.
I don't think we can do this at this time. E.g. the following program works even with GCC 5 and -std=c++14: constexpr int foo (int n) { int a[n] = { 1, 2, 3 }; int z = 0; for (unsigned i = 0; i < 3; ++i) z += a[i]; return z; } int main () { constexpr int n = foo (3); __builtin_printf ("%d\n", n); } So starting to reject such a code might broke working programs. And we're able to reject non-standard code: -pedantic-errors. > FWIW, it seems to me the fewer extensions we support the less risk > of something going wrong because of unforeseen interactions with > other features. True... (hi statement expressions!). Marek