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

Reply via email to