Re: [C++ PATCH] 79118 bitfields & constexpr

[Jason Merrill <jason at redhat dot com>]

OK.

On Tue, Jan 24, 2017 at 1:53 PM, Nathan Sidwell <nathan@acm.org> wrote:
> On 01/24/2017 01:41 PM, Jason Merrill wrote:
>>
>> On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell <nathan@acm.org> wrote:
>>>
>>> On 01/23/2017 04:06 PM, Jason Merrill wrote:
>>>
>>>>> In this particular case we've also made the base object the containing
>>>>> class, not the unnamed struct member.  That means we're looking in the
>>>>> wrong
>>>>> CONSTRUCTOR and see CONSTRUCTOR_NO_IMPLICIT_ZERO is true.  Whereas for
>>>>> the
>>>>> subobj's CONSTRUCTOR it is false.
>>>>
>>>>
>>>>
>>>> Why is it false?
>>>
>>>
>>>
>>> I thought it was because we're looking at a different level of ctor,
>>> investigation shows there may be a bug there too. because in one place we
>>> do:
>>>      if (*valp == NULL_TREE)
>>>         {
>>>           *valp = build_constructor (type, NULL);
>>>           CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp) = no_zero_init;
>>> and another we do:
>>>       if (vec_safe_is_empty (*vec)
>>>           || (*vec)->last().index != field)
>>>         {
>>>           ctor = build_constructor (TREE_TYPE (field), NULL);
>>>           CONSTRUCTOR_APPEND_ELT (*vec, field, ctor);
>>>
>>> However, further looking at this problem, I discovered we're not properly
>>> checking the initialization of anonymous members.  Once we do that, we
>>> reject the ctor as a constexpr, because it fails to initialize the 'type'
>>> member (regardless of bitfieldness).
>>>
>>> This patch augments cx_check_missing_mem_inits.  I change the first parm
>>> to
>>> be the CTYPE not the FUN from whence we pull the CTYPE.  That way we
>>> don't
>>> have to cons up an empty CONSTRUCTOR for the recursive case of
>>> discovering
>>> no initializer at all for the anon member.
>>>
>>> With this in place we don't try and evaluate the constexpr in the
>>> original
>>> testcase.
>>>
>>> ok?
>>
>>
>> I'm not seeing the patch.
>
>
> d'oh!
>
>
>
> --
> Nathan Sidwell