Jason,
Have you had a chance to review the patch below and consider
the ABI ramifications I mentioned?
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01901.html
Thanks
Martin
On 01/25/2016 09:55 AM, Martin Sebor wrote:
On 01/21/2016 04:32 PM, Martin Sebor wrote:
On 01/21/2016 04:19 PM, Jason Merrill wrote:
Can we reconsider the representation of flexible arrays? Following the
example of the C front-end is causing a lot of trouble, and using a null
TYPE_DOMAIN seems more intuitive.
I remember running into at least one ICE in the middle end with
the alternate representation (null TYPE_DOMAIN). At this late
stage I would worry about the fallout from that. It seems that
outside of 69251 and 69277 the problems are mostly triggered by
ill-formed code that wasn't being tested and I'm hoping that
the problems in the well-formed cases have been reported (and
with the patches I've sent fixed).
At the same time, based on some debugging I had to do for 69251
(ICE in unify_array_domain on a flexible array member) it seems
that it might make handling them in template easier.
In a discussion with Jason in IRC I agreed to submit a patch
changing the representation of flexible array members in the C++
front end to use a null domain rather than a domain with a null
upper bound. Attached is a patch making the requested change.
It fixes the following bugs:
c++/69251 - [6 Regression] ICE in unify_array_domain on a flexible
array member
(the bug in the Subject)
c++/69253 - [6 Regression] ICE in cxx_incomplete_type_diagnostic
initializing a flexible array member with empty string
with the original patch here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01325.htm
and
c++/69290 - [6 Regression] ICE on invalid initialization
of a flexible array member
with the original patch here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01685.html
as well as
c++/69277 - [6 Regression] ICE mangling a flexible array member
with its final patch posted here
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01233.html
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.
I successfully tested the new patch on x86_64.
Martin
