https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase in comment#2 we end up with
<bb 2> [local count: 1073741824]:
MEM[(struct __as_base &)&a] ={v} {CLOBBER};
a.m = 0;
_5 = operator new [] (0);
a.p = _5;
_2 = a.m;
if (_2 > 0)
goto <bb 3>; [89.00%]
else
goto <bb 5>; [11.00%]
and the code diagnosed is in the unreachable branch we cannot resolve as not
taken because 'operator new [] (0)' is thought to clobber 'a.m'.
We've been circling around improving alias analysis around new and delete
but since users can override them we threw the towel.
For the original testcase in g++.dg/pr71488.C we have
<bb 5> [local count: 214748368]:
*_51._M_size = 0;
_147 = operator new (0);
<bb 6> [local count: 214748368]:
*_51._M_data = _147;
_101 = *_51._M_size;
_99 = _101 * 8;
__builtin_memcpy (_147, _72, _99);
so again we fail to CSE '*_51._M_size' because of 'operator new (0)' but
also the diagnostic code simply assumes that size is at least 1 and
doesn't consider zero here for "reasons".
Note I think there's still a bug in value_range (irange) here. get_size_range
does
if (integral)
{
value_range vr;
query->range_of_expr (vr, exp, stmt);
if (vr.undefined_p ())
vr.set_varying (TREE_TYPE (exp));
range_type = vr.kind ();
min = wi::to_wide (vr.min ());
max = wi::to_wide (vr.max ());
and we have vr:
(gdb) p vr
$13 = {<irange> = {<vrange> = {
_vptr.vrange = 0x3693a30 <vtable for int_range<1u>+16>,
m_kind = VR_ANTI_RANGE, m_discriminator = VR_IRANGE},
m_num_ranges = 1 '\001', m_max_ranges = 1 '\001',
m_nonzero_mask = <tree 0x0>, m_base = 0x7fffffffc8f0}, m_ranges = {
<integer_cst 0x7ffff68143f0>, <integer_cst 0x7ffff5e82090>}}
(gdb) p vr.dump (stderr)
[irange] unsigned int [0, 0][8, +INF]$17 = void
but vr.min () produces 1 and vr.max () produces 7, just as if it doesn't
interpret VR_ANTI_RANGE transparently here (if that's the intent?!).
At least
// Return the highest bound of a range expressed as a tree.
inline tree
irange::tree_upper_bound () const
suggests that. Note that vr.num_pairs () produces 2 (because constant_p ())
but vr.m_num_ranges is 1 and tree_upper_bound uses m_num_ranges.
I suppose irange::{min,max,tree_lower_bound,tree_upper_bound} miss "support"
for legacy_mode_p here.
Either using int_range<2> or vr.lower_bound/upper_bound works to avoid this
issue. Still it's fragile. I suppose since 'value_range' is legacy
itself using int_range<2> is better here. So I'm testing the following
to get rid of that legacy, plus get rid of ::min/max which are legacy as well.
