This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] c++/78765
- From: Nathan Sidwell <nathan at acm dot org>
- To: Jason Merrill <jason at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 4 Jan 2017 09:33:44 -0500
- Subject: Re: [PATCH] c++/78765
- Authentication-results: sourceware.org; auth=none
- References: <af30b5d3-07a7-78e2-d0ea-930cc5e00ae6@acm.org> <4e074ce1-b1d5-87c9-2593-713ccc5daf92@redhat.com>
On 01/04/2017 12:40 AM, Jason Merrill wrote:
On 12/16/2016 07:23 AM, Nathan Sidwell wrote:
when cxx_eval_constant_expression finds a nonconstant expression it
returns a TREE without TREE_CONSTANT set.
else if (non_constant_p && TREE_CONSTANT (r))
{
/* This isn't actually constant, so unset TREE_CONSTANT. */
Hmm, we shouldn't get here for an expression we're going to use as an
lvalue.
I don't think we know we're going to use it as an lvalue early enough.
We get here from convert_nontype_argument:
else if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
expr = maybe_constant_value (expr);
and fail to have 'var' as a constexpr (because it had a bogus
initializer, for which we emitted a diagnostic).
We then get to:
if (INTEGRAL_OR_ENUMERATION_TYPE_P (type))
{
tree t = build_integral_nontype_arg_conv (type, expr, complain);
and that finds the conversion operator, which needs var as the object
expression.
I suppose at that point, if expr is not constant we've already lost.
Perhaps build_integral_nontype_arg_conv should bail out earlier?
Or is the problem in the error recovery of:
static constexpr ValueType var = 0;
should we unmark the constexprness of var?
WDYT?
nathan
--
Nathan Sidwell