On 04/15/2016 06:31 AM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 09:26:11AM -0600, Martin Sebor wrote:
/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C: In instantiation
of 'struct TestType<32u>':
/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C:201:1:
r
On Thu, Apr 14, 2016 at 09:26:11AM -0600, Martin Sebor wrote:
> >/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C: In
> >instantiation of 'struct TestType<32u>':
> >/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C:201:1:
> >required from here
> >/daten/aranym/g
On 14 April 2016 at 17:26, Martin Sebor wrote:
> On 04/14/2016 04:39 AM, Andreas Schwab wrote:
>>
>> Martin Sebor writes:
>>
>>> diff --git a/gcc/testsuite/g++.dg/cpp1y/vla11.C
>>> b/gcc/testsuite/g++.dg/cpp1y/vla11.C
>>> new file mode 100644
>>> index 000..af9624a
>>> --- /dev/null
>>> +++ b
It caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70652
Sorry about that (I missed java among the languages when configuring
my build for regression testing). I'm testing a libjava patch that
I expect will eliminate the linker error.
Martin
On 04/14/2016 04:39 AM, Andreas Schwab wrote:
Martin Sebor writes:
diff --git a/gcc/testsuite/g++.dg/cpp1y/vla11.C
b/gcc/testsuite/g++.dg/cpp1y/vla11.C
new file mode 100644
index 000..af9624a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/vla11.C
@@ -0,0 +1,711 @@
+// PR c++/69517 - [5/6
Martin Sebor writes:
> diff --git a/gcc/testsuite/g++.dg/cpp1y/vla11.C
> b/gcc/testsuite/g++.dg/cpp1y/vla11.C
> new file mode 100644
> index 000..af9624a
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1y/vla11.C
> @@ -0,0 +1,711 @@
> +// PR c++/69517 - [5/6 regression] SEGV on a VLA with ex
On Wed, Apr 13, 2016 at 11:36 AM, Martin Sebor wrote:
> On 04/12/2016 12:17 PM, Jason Merrill wrote:
>>
>> On 04/10/2016 07:14 PM, Martin Sebor wrote:
>>>
>>> The call to build_vla_check() in check_initializer() is to check
>>> only explicitly initialized VLAs. The latter function may need
>>> to
On 04/13/2016 02:36 PM, Martin Sebor wrote:
I don't see the benefit in doing the checking in build_vec_init
and split_constant_init_1 when it can all be done just in
check_initializer. I'm sure you have your reasons for going that
route so I'd appreciate if you could let me know why you think
th
On 04/12/2016 12:17 PM, Jason Merrill wrote:
On 04/10/2016 07:14 PM, Martin Sebor wrote:
The call to build_vla_check() in check_initializer() is to check
only explicitly initialized VLAs. The latter function may need
to complete the VLA element type and reshape the initializer so
the call canno
On 04/10/2016 07:14 PM, Martin Sebor wrote:
The call to build_vla_check() in check_initializer() is to check
only explicitly initialized VLAs. The latter function may need
to complete the VLA element type and reshape the initializer so
the call cannot be made earlier. The function returns the r
On 04/12/2016 09:43 AM, Jason Merrill wrote:
On 04/10/2016 07:14 PM, Martin Sebor wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE
+ && variably_modified_type_p (type, NULL_TREE)
+ && !processing_template_decl)
+{
+ /* Statically check for overflow in VLA bound
On 04/10/2016 07:14 PM, Martin Sebor wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE
+ && variably_modified_type_p (type, NULL_TREE)
+ && !processing_template_decl)
+ {
+ /* Statically check for overflow in VLA bounds and build
+an
Attached is an updated patch with some the changes you suggested.
I also moved the new functions from decl.c to init.c because they
logically seem to belong there.
The suggested changes resulted in introducing the checking code
into split_nonconstant_init() in cp/typeck2.c in addition to
build_ve
I've spent a ton of time trying to implement the suggested
changes (far too much in large part because of my own mistakes)
but I don't think they will work. I'll try to clean up what
I have and post it for review. I wanted to respond to this
how in case you have some suggestions or concerns with
On 04/01/2016 07:02 PM, Martin Sebor wrote:
Fair enough. I don't think we can impose an arbitrary 64K limit,
however, as that is a lot smaller than the 8MB default stack size, and
programs can use setrlimit to increase the stack farther. For GCC 6 let
not impose any limit beyond non-negative/ov
Fair enough. I don't think we can impose an arbitrary 64K limit,
however, as that is a lot smaller than the 8MB default stack size, and
programs can use setrlimit to increase the stack farther. For GCC 6 let
not impose any limit beyond non-negative/overflowing, and as you say we
can do something
On 03/23/2016 03:47 PM, Martin Sebor wrote:
Thanks for the comments.
2) It hardwires a rather arbitrarily restrictive limit of 64 KB
on the size of the biggest C++ VLA. (This could stand to be
improved and made more intelligent, and perhaps integrated
with stack checking via -fstac
Thanks for the comments.
2) It hardwires a rather arbitrarily restrictive limit of 64 KB
on the size of the biggest C++ VLA. (This could stand to be
improved and made more intelligent, and perhaps integrated
with stack checking via -fstack-limit, after the GCC 6
release.)
The
On 03/06/2016 08:38 PM, Martin Sebor wrote:
There are a few additional points to note about the patch:
1) It restores the std::bad_array_length exception from N3639,
even though the class isn't specified by the C++ standard.
At first I thought that introducing a different (private)
t
I'm looking for a review of the patch below. I noticed a piece
of commented out code in there. Please assume that I will remove
it before the final commit.
As a heads up, I'm traveling this Thursday through Sunday and
won't have access to email to answer questions or address
comments until next
Ping:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html
On 03/06/2016 06:38 PM, Martin Sebor wrote:
GCC 4.9 had added support for C++ VLAs as specified in WG21
document N3639 expected to be included in C++ 14. However,
WG21 ultimately decided not to include N3639 in C++ 14 and
the G++
GCC 4.9 had added support for C++ VLAs as specified in WG21
document N3639 expected to be included in C++ 14. However,
WG21 ultimately decided not to include N3639 in C++ 14 and
the G++ support was partially removed in 5.1. Unfortunately,
the removal rendered some safe albeit erroneous G++ 4.9 c
22 matches
Mail list logo
