This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] fix #69251 - [6 Regression] ICE in unify_array_domain on a flexible array member
- From: Jason Merrill <jason at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Feb 2016 13:28:23 +0100
- Subject: Re: [PATCH] fix #69251 - [6 Regression] ICE in unify_array_domain on a flexible array member
- Authentication-results: sourceware.org; auth=none
- References: <569D9FAB dot 90705 at gmail dot com> <56A16774 dot 8040609 at redhat dot com> <56A16A86 dot 3030102 at gmail dot com> <56A6538C dot 9030602 at gmail dot com>
On 01/25/2016 05:55 PM, Martin Sebor wrote:
The downside of this approach is that it prevents everything but
the front end from distinguishing flexible array members from
arrays of unspecified or unknown bounds. The immediate impact
is that prevents us from maintaining ABI compatibility with GCC
5 (with -fabi-version=9) and from diagnosing the mangling change.
This means should we decide to adopt this approach, the final
version of the patch for c++/69277 mentioned above that's still
pending approval will need to be tweaked to have the ABI checks
removed.
That's unfortunate, but I think acceptable.
* decl.c (compute_array_index_type): Return null for flexible array
members.
Instead of this, I would think we can remove the calls to
compute_array_index_type added by your earlier patch, as well as many
other changes from that patch to handle null TYPE_MAX_VALUE.
* tree.c (array_of_runtime_bound_p): Handle gracefully array types
with null TYPE_MAX_VALUE.
This seems unneeded.
(build_ctor_subob_ref): Loosen debug checking to handle flexible
array members.
And this shouldn't need the TYPE_MAX_VALUE check.
Jason