This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr
On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell <nathan@acm.org> wrote:
> On 04/20/2018 01:44 PM, Jason Merrill wrote:
>
> > Any time we need an actual adjustment, there will be a PLUS_EXPR. The
> > issue is somehow distinguishing between a reinterpret_cast and one of
> > the many other sources of NOP_EXPR.
>
> yeah, I see that now. Perhaps VIEW_CONVERT_EXPR is more appropriate for
> the reinterpret_cast case?
>
No, VIEW_CONVERT_EXPR is a glvalue; it would only be appropriate for
conversion to reference type.
Anyway, such a change would require auditing a lot of NOP_EXPR uses.
> This less invasive patch instead adds a REINTERPRET_CAST_P flag, which
> we set on NOP_EXPRs coming out of build_reinterpret_1. Then in
> cxx_eval_constant_expression we reject any NOP_EXPR that has that flag
> set. We can get rid of the subsequent special casing of a NOP_EXPR
> involving a PTRMEM_CST.
Sounds good.
> I have to change convert_ptrmem to always
> expand the constant (into an OFFSET_TYPE) so that
> initializer_constant_valid_p (used by reduced_constant_expression_p)
> doesn't get confused by a zero-adjusting conversion of a ptrmem_cst.
>
Hmm, I'm nervous about this change. Maybe teach r_c_e_p to handle this
case properly?
cpp0x/addressof1.C thinks thinks like
> 'static_assert (reinterpret_cast <T*>(&thing) == &thing.member)'
> are constant expressions, but AFAICT they are not
>
Agreed.
cpp0x/constexpr-pmf1.C is checking an optimization occurs at the
> genericization level without turning the optimizer on. IMHO we only
> need to check this is happening at some point when the optimizer is
> turned on. (The original bug was wrong code, but then perhaps it should
> be a runtime check?)
>
Maybe test this with just -O1?
Jason