On 03/21/2016 06:09 PM, Jeff Law wrote:
On 03/21/2016 11:54 AM, Jason Merrill wrote:
Both b0 and b1 are invalid and should be diagnosed, but only b1
is. b1 isn't because because by the time we see its initializer
in constexpr.c it's been transformed into the equivalent of "b1
= (int*)ps" (though we don't see the cast which would also make
it invalid).
But if we can avoid these early simplifying transformations and
retain a more faithful representation of the original source then
doing the checking later will likely be simpler and result in
detecting more problems with greater consistency and less effort.
Do we know where the folding is happening for this case and is it
something we can reasonably defer? ie, is this just a case we missed
as part of the deferred folding work and hence should have its own
distinct BZ to track?
Yes, why is it already folded?
Let's pull that out into a separate BZ and tackle it for gcc-7.
I need to understand the issue before I agree to defer it.
It turns out that the problem is with how cp_build_binary_op calls
cp_pointer_int_sum and thus the c-common pointer_int_sum, which folds.
The POINTER_PLUS_EXPRs thus created have been a source of many issues
with constexpr evaluation, since it's impossible to reconstruct the
original expression, especially because POINTER_PLUS_EXPR uses an
unsigned second operand. Deferring lowering to POINTER_PLUS_EXPR would
help a lot. But it would indeed be a significant risk at this point.
I think let's defer the fix for c++/60760 (i.e. the nullptr_p bits)
until stage 1, when it can be combined with the POINTER_PLUS_EXPR fix,
and put the rest of this patch in now.
Jason
