This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH to fix bogus error with constexpr and empty class (PR c++/81933)
- From: Jason Merrill <jason at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 22 Jan 2018 09:40:50 -0500
- Subject: Re: C++ PATCH to fix bogus error with constexpr and empty class (PR c++/81933)
- Authentication-results: sourceware.org; auth=none
- References: <20180118223919.GE3914@redhat.com>
On Thu, Jan 18, 2018 at 5:39 PM, Marek Polacek <polacek@redhat.com> wrote:
> The problem in this PR is that we get
> error: constexpr call flows off the end of the function
> for a valid testcase, but not in C++17 mode. That's because in C++17 we
> execute:
>
> 4321 if (cxx_dialect >= cxx17 && !BINFO_VIRTUAL_P (binfo))
> 4322 {
> 4323 tree decl = build_base_field_1 (t, basetype, next_field);
> 4324 DECL_FIELD_OFFSET (decl) = BINFO_OFFSET (binfo);
> 4325 DECL_FIELD_BIT_OFFSET (decl) = bitsize_zero_node;
> 4326 SET_DECL_OFFSET_ALIGN (decl, BITS_PER_UNIT);
> 4327 }
>
> which puts some additional fields into some classes. This makes a difference
> for split_nonconstant_init:
>
> 751 if (split_nonconstant_init_1 (dest, init))
> 752 init = NULL_TREE;
>
> where split_nonconstant_init_1 is true so that means that the DECL_INITIAL will
> be null. Why is split_nonconstant_init_1 true? Because it ends up calling
> complete_ctor_at_level_p with
>
> 6114 return count_type_elements (type, true) == num_elts;
>
> but the count_type_elements result differs between c++14/c++17 precisely
> because of the fields added in build_base_field. But we should only add those
> fields when initializing aggregates with bases, which is not what's happening
> in this testcase.
>
> With DECL_INITIAL being null, we error here (result is NULL):
>
> 1702 result = *ctx->values->get (slot ? slot : res);
> 1703 if (result == NULL_TREE && !*non_constant_p)
> 1704 {
> 1705 if (!ctx->quiet)
> 1706 error ("%<constexpr%> call flows off the end "
> 1707 "of the function");
> 1708 *non_constant_p = true;
> 1709 }
>
> I think the problem is that we're dealing with an empty class here, for which
> we should just generate an empty ctor, as in few other spots.
This seems like a workaround rather than a fix; we should fix
split_nonconstant_init to work properly rather than override it.
Specifically, it seems odd to return true if num_elts is 0; we
shouldn't override DECL_INITIAL if we didn't actually split anything
out.
Jason