OK.
On Tue, Jan 24, 2017 at 1:53 PM, Nathan Sidwell <nat...@acm.org> wrote:
> On 01/24/2017 01:41 PM, Jason Merrill wrote:
>>
>> On Tue, Jan 24, 2017 at 1:31 PM, Nathan Sidwell <nat...@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
