On Fri, Apr 20, 2018, 12:52 PM Nathan Sidwell <nat...@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