On 10/01/2015 03:49 AM, Richard Biener wrote:
On Wed, Sep 30, 2015 at 6:43 PM, Jeff Law <l...@redhat.com> wrote:
On 09/30/2015 01:48 AM, Richard Biener wrote:
On Tue, Sep 29, 2015 at 6:55 PM, Jeff Law <l...@redhat.com> wrote:
The pdp11 port fails to build with the trunk because of a warning.
Essentially VRP determines that the result of using BRANCH_COST is a
constant with the range [0..1]. That's always less than 4, 3 and the
various other magic constants used with BRANCH_COST and VRP issues a
warning
about that comparison.
It does? Huh. Is it about undefined overflow which is the only thing
VRP should end up
warning about? If so I wonder how that happens, at least I can't
reproduce it for
--target=pdp11 --enable-werror build of cc1.
You have to use a trunk compiler to build the pdp11 cross. You'll bump into
this repeatedly:
if (warn_type_limits
&& ret && only_ranges
&& TREE_CODE_CLASS (code) == tcc_comparison
&& TREE_CODE (op0) == SSA_NAME)
{
/* If the comparison is being folded and the operand on the LHS
is being compared against a constant value that is outside of
the natural range of OP0's type, then the predicate will
always fold regardless of the value of OP0. If -Wtype-limits
was specified, emit a warning. */
tree type = TREE_TYPE (op0);
value_range_t *vr0 = get_value_range (op0);
if (vr0->type == VR_RANGE
&& INTEGRAL_TYPE_P (type)
&& vrp_val_is_min (vr0->min)
&& vrp_val_is_max (vr0->max)
&& is_gimple_min_invariant (op1))
{
location_t location;
if (!gimple_has_location (stmt))
location = input_location;
else
location = gimple_location (stmt);
warning_at (location, OPT_Wtype_limits,
integer_zerop (ret)
? G_("comparison always false "
"due to limited range of data type")
: G_("comparison always true "
"due to limited range of data type"));
}
}
Oh, I didn't remember we have this kind of warning in VRP ... it's
bound to trigger
for example after jump-threading. So I'm not sure it's useful.
It caught me by surprise as well. It's a poor man's attempt at
unreachable code warnings. Strangely, it's been around since 2009, but
is only just now causing problems. I'd certainly question it's utility
as well.
That may be a symptom of something else not optimizing the condition
earlier or we've made some changes that expose the collapsed range to VRP.
Jef
