[C++ RFH/Patch] PR 52892 (and others)

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

it would be nice to make progress on some constexpr issues, thus I 
started looking more closely into c++/52892, which comes with a compact 
testcase and a useful comparison with a snippet for which we already do 
the right thing (thanks to Daniel). Thus:

constexpr bool is_negative(int x) { return x < 0; }
constexpr bool check(int x, bool (*p)(int)) { return p(x); }
static_assert(check(-2, is_negative), "Error");

vs

constexpr bool is_negative(int x) { return x < 0; }
typedef bool (*Function)(int);
constexpr bool check(int x, Function p) { return p(x); }
static_assert(check(-2, is_negative), "Error");

the difference, for the latter and for more complex cases, is that 
adjust_temp_type calls cp_fold_convert which ends up returning a 
NOP_EXPR (eg, build in fold_convert_loc). This NOP_EXPR eventually 
appears as return value of the cxx_eval_constant_expression at the 
beginning of cxx_eval_call_expression. Of course, there are many 
different ways in which such NOP_EXPR can be returned and, well, if only 
we could look through it, we would find an ADDR_EXPR and all such cases 
(eg, in c++/52282 too) would be easily handled by the rest of 
cxx_eval_call_expression. Today I wondered: at least when we are *sure* 
that we are handling a function pointer, would it be correct to actually 
use STRIP_NOPS on what cxx_eval_constant_expression returns?!? The 
attached passes testing anyway...

Thanks,
Paolo Carlini

Attachment: p
Description: Text document