On 01/28/2016 03:27 PM, Marek Polacek wrote:
On Wed, Jan 27, 2016 at 09:52:13AM -0700, Martin Sebor wrote:
This happens to work but I suspect it's only by accident. When
the number of elements in the initializer is increased to exceed
the number of elements in the VLA GCC gets into infinite rec
On Wed, Jan 27, 2016 at 09:52:13AM -0700, Martin Sebor wrote:
> This happens to work but I suspect it's only by accident. When
> the number of elements in the initializer is increased to exceed
> the number of elements in the VLA GCC gets into infinite recursion.
> (I opened bug 69516 with a test
On 01/27/2016 11:52 AM, Martin Sebor wrote:
I agree that there is some risk that it might break some working
programs. I would expect the most common use of initialized VLAs
be to set all elements to zero using the "= { }" or "= { 0 }"
syntax. Initializers with more elements are, IMO, likely to
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 ar
On Wed, Jan 27, 2016 at 09:08:27AM -0500, Jason Merrill wrote:
> OK, but the testcase should go in ext/.
Oops, will move it there then, thanks!
Marek
OK, but the testcase should go in ext/.
Jason
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
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 abl
