[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-03-07 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Patch for bug 69517 posted for review (below) includes a fix for this bug as well: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Eric Gallager changed: What|Removed |Added Keywords||patch CC||egallager at gcc dot gnu.org, ||jason at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69517 --- Comment #2 from Eric Gallager --- (In reply to Martin Sebor from comment #1) > Patch for bug 69517 posted for review (below) includes a fix for this bug as > well: > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html Adding "patch" keyword then
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Martin Sebor changed: What|Removed |Added Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #8 from Martin Sebor --- I'm no longer working on this.
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 --- Comment #3 from Eric Gallager --- (In reply to Martin Sebor from comment #0) > The G++ 4.9 Changes document (https://gcc.gnu.org/gcc-4.9/changes.html) > claims support for C++ VLAs including initializers (as specified in N3639). I thought that proposal was withdrawn, meaning that VLA support in G++ is now only as a GNU extension again, like it was previously? Or am I getting it confused with something else? > The N3639 proposal specifies that the /expression/ denoting the number of > elements in a VLA declaration is erroneous when "the initializer of the > object is a braced-init-list whose number of (top-level) initializer-clauses > exceeds the number of elements to initialize." The proposal then goes on to > say that if an /expression/ that is not a core-constant expression is > erroneous, an exception of a type that would match a handler (15.3 > except.handle) of type std::bad_array_length (18.6.2.2 xxx) is thrown." > > The following test case shows an example where G++ fails to follow this > requirement. > > AFAICS, the problem is that this checking in G++ 4.9 is implemented in the > wrong function (build_vec_init() in cp/init.c). The checking needs to be > done in its caller, store_init_value(), because it only calls > build_vec_init() when array_of_runtime_bound_p(type) is true, and that > function only consider the major rank of the array, not any of its minor > ranks). > > $ cat z.cpp && /home/msebor/build/gcc-4.9.3/gcc/xgcc > -B/home/msebor/build/gcc-4.9.3/gcc -Wall -Wextra -Wpedantic -xc++ z.cpp && > ./a.out > void __attribute__ ((noclone, noinline)) foo (void*) { } > void __attribute__ ((noclone, noinline)) bar (int n) > { > char a [1][n] = { { 0, 1, 2 } }; > foo (a); > } > > int main () > { > try { > bar (1); > __builtin_abort (); > } > catch (...) { > } > } > z.cpp: In function ‘void bar(int)’: > z.cpp:4:15: warning: ISO C++ forbids variable length array ‘a’ [-Wvla] >char a [1][n] = { { 0, 1, 2 } }; >^ > Aborted (core dumped)
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- (In reply to Eric Gallager from comment #3) > (In reply to Martin Sebor from comment #0) > > The G++ 4.9 Changes document (https://gcc.gnu.org/gcc-4.9/changes.html) > > claims support for C++ VLAs including initializers (as specified in N3639). > > I thought that proposal was withdrawn, meaning that VLA support in G++ is > now only as a GNU extension again, like it was previously? Or am I getting > it confused with something else? No, that's correct.
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 --- Comment #5 from Eric Gallager --- (In reply to Marek Polacek from comment #4) > (In reply to Eric Gallager from comment #3) > > (In reply to Martin Sebor from comment #0) > > > The G++ 4.9 Changes document (https://gcc.gnu.org/gcc-4.9/changes.html) > > > claims support for C++ VLAs including initializers (as specified in > > > N3639). > > > > I thought that proposal was withdrawn, meaning that VLA support in G++ is > > now only as a GNU extension again, like it was previously? Or am I getting > > it confused with something else? > > No, that's correct. So, if it's only a GNU extension again, that means GCC can just do whatever, right? Is it worth changing behavior here just to match a proposal that's no longer relevant?
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 --- Comment #6 from Martin Sebor --- The current behavior in this case is undefined. That should be avoided when it can be done without excessive overhead. Throwing an exception instead has only negligible overhead and is preferable to letting programs trash their stack. The original patch that did that was approved and committed but caused a linker error while building libgcj.so due to its own problems (pr70652). Because it was too close to GCC 6 release it ended up getting reverted instead of fixing libgcj. I've been meaning to resubmit the patch for each release after that but I never seem to get around to it. Hopefully for GCC 10.
[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70652 --- Comment #7 from Eric Gallager --- (In reply to Martin Sebor from comment #6) > The current behavior in this case is undefined. That should be avoided when > it can be done without excessive overhead. Throwing an exception instead > has only negligible overhead and is preferable to letting programs trash > their stack. The original patch that did that was approved and committed > but caused a linker error while building libgcj.so due to its own problems > (pr70652). Because it was too close to GCC 6 release it ended up getting > reverted instead of fixing libgcj. I've been meaning to resubmit the patch > for each release after that but I never seem to get around to it. Hopefully > for GCC 10. Well since libgcj is no longer part of GCC, that part should no longer be an issue at least!