Hi,
On 22/03/2018 19:08, Jason Merrill wrote:
On Thu, Mar 22, 2018 at 4:05 AM, Paolo Carlini <paolo.carl...@oracle.com> wrote:
Hi,
yesterday I figured out that this issue is in fact orthogonal to possible
improvements to maybe_deduce_size_from_array_init, indeed it happens also
when we are not deducing the size. The testcase is very similar to that
recently submitted for c++/78345, which led Jason to add the bit of
additional checking around the middle of build_aggr_init. Since we did
already have a similar check a bit earlier - not requiring the computation
of from_array - I added one for VAR_DECLs too in the same place and
tweaked/improved a bit the error message in the process (a few greps
revealed that we don't seem to have any other generic error message using
the form "bad ..."), consistently with the diagnostic that we already
provide for, eg, a simple
int a[2] = a;
FYI, I must also add that entire testsuite doesn't have a test triggering
the existing TREE_CODE (init) == TREE_LIST check, and failed so far to
construct one... (many such issues are normally catched by digest_init).
Tested x86_64-linux.
That whole block is there to support this sort of initialization, as
an ancient extension. Since it isn't generally allowed, and is
causing trouble, let's remove it and reject anything that isn't an
initializer list.
Nice. While I start implementing the above, any hint about thing like
g++.dg/cpp0x/initlist68.C, which we would reject because involves a
plain constructor of type ARRAY_TYPE, not a proper
BRACE_ENCLOSED_INITIALIZER_P? Also, less important I guess, we would
also reject g++.dg/torture/pr70499.C to which you added -fpermissive in
the occasion of c++/78345. Or maybe you meant something a bit less
drastic ;)
Paolo.
