[PATCH] [PR c++/85437] accept static_casted ptrmem in constexpr

[Nathan Sidwell]

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?

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.  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.

cpp0x/addressof1.C thinks thinks like
'static_assert (reinterpret_cast <T*>(&thing) == &thing.member)'
are constant expressions, but AFAICT they are not
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?)

WDYT?

nathan
-- 
Nathan Sidwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 85437.diff
Type: text/x-patch
Size: 14324 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20180420/0fc64e49/attachment.bin>