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

[Nathan Sidwell <nathan at acm dot org>]

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?

nathan

--
Nathan Sidwell