On 03/22/2016 04:01 PM, Martin Sebor wrote:
On 03/22/2016 12:52 PM, Jason Merrill wrote:
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.
I can split up the patch into two and post the subset without
the fix for c++/60760, though I don't expect to be done with
it after I get back (next week).
I'd like to understand your concern with the fix for c++/60760.
Is it that it's incomplete (doesn't reject taking the address
of the first member of a struct, as in &null->first_member),
or are you worried that the changes may not be stable enough?
More the latter; it seems like significant new code and doesn't fix a
regression.
Jason
