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.
