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
