[C++ Patch/RFC] PR 60047

[Paolo Carlini]

Hi,

On 02/04/2014 12:51 PM, Paolo Carlini wrote:
> Hi,
>
> thus I tried to have a look to this issue, while experiencing some 
> weird problems with the debugger, which slowed me down a lot. I have 
> been able to figure out that we don't seem to actively set constexpr_p 
> to true anywhere in implicitly_declare_fn (besides the unrelated case 
> of inheriting constructors), thus I'm wondering if it would make sense 
> to simply do the below?!? (and revert my recent tweak)
I spent a little more time on this. Outside the case of inheriting 
constructors and the special case of expected_trivial default 
constructors (which are handled in a special conditional), we are 
normally assigning true to constexpr_p only in one place, that is close 
to the beginning of synthesized_method_walk:

   /* If that user-written default constructor would satisfy the
      requirements of a constexpr constructor (7.1.5), the
      implicitly-defined default constructor is constexpr.  */
   if (constexpr_p)
     *constexpr_p = ctor_p;

then, for the testcase at issue it becomes false in the place which we 
already discussed for the ICE:

   if (vec_safe_is_empty (vbases))
     /* No virtual bases to worry about.  */;
   else if (!assign_p)
     {
       if (constexpr_p)
     *constexpr_p = false;

Then it doesn't gets a chance to return true. Thus, given the more 
accurate analysis, I think that we either do what I quickly proposed 
yesterday, or alternately, the only option I can see, we change 
process_subob_fn to set it to true in some cases (but I note that it 
does never set to true trivial_p).

Thanks,
Paolo.