http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The issue, as I understand it, is that in check_initializer, in C++11 mode, we
enter this block

      if ((type_build_ctor_call (type) || CLASS_TYPE_P (type))
          && !(flags & LOOKUP_ALREADY_DIGESTED)
          && !(init && BRACE_ENCLOSED_INITIALIZER_P (init)
               && CP_AGGREGATE_TYPE_P (type)
               && (CLASS_TYPE_P (type)
                   || type_has_extended_temps (type))))
        {

because type_build_ctor_call (type) is true in C++11, but false in C++03, and
here we basically only set LOOKUP_ALREADY_DIGESTED.  Then later on in
store_init_value we have

  if (flags & LOOKUP_ALREADY_DIGESTED)
    value = init;
  else 
    /* Digest the specified initializer into an expression.  */
    value = digest_init_flags (type, init, flags);

as a result, in C++11 "value" is {{1}}, while in C++03 {{.i=1}}.  In C++03, we
save this into DECL_INITIAL and everything looks peachy, but in C++11 we call
split_nonconstant_init and from there the things go wrong, I'd say.

I'm not clear on whether type_build_ctor_call should for struct s[1] return
true or false.
It's also interesting why type_build_ctor_call returns false in C++03, it has
this check

  if (cxx_dialect < cxx11)
    return false;

but that can be dropped and it still returns false.  The difference is in new
hunk that came with r203985:

  /* A user-declared constructor might be private, and a constructor might
     be trivial but deleted.  */
  for (tree fns = lookup_fnfields_slot (inner, complete_ctor_identifier);
       fns; fns = OVL_NEXT (fns))
    {    
      tree fn = OVL_CURRENT (fns);
      debug_tree (fn);
      if (!DECL_ARTIFICIAL (fn) 
          || DECL_DELETED_FN (fn))
        return true;
    }

in C++03, there are two __comp_ctor's, in C++11 there are three __comp_ctor's,
and the last one is DECL_DELETED_FN, thus we return true.  Why is that I have
no clue whatsoever.

So, this all boils down to whether type_build_ctor_call is correct, or whether
I should be looking for a bug elsewhere.

Reply via email to