On 03/16/2016 06:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static void
+warn_for_null_address (location_t locat
On 03/17/2016 10:48 AM, Patrick Palka wrote:
On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law wrote:
On 03/16/2016 06:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibl
On 03/17/2016 10:45 AM, Jason Merrill wrote:
On 03/16/2016 08:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static
While I would find the warning less misleading if it simply said
in all three cases: "the address of 'x' will always evaluate as
‘true’" I think it would be even more accurate if it said
"the address of 'x' may be assumed to evaluate to ‘true’" That
avoids making claims about whether or not it ac
On 03/16/2016 08:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static void
+warn_for_null_address (location_t locat
On Wed, Mar 16, 2016 at 06:43:39PM -0600, Martin Sebor wrote:
> >@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
> >return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
> > }
> >
> >+/* Possibly warn about an address never being NULL. */
> >+
> >+static void
> >
On 03/17/2016 02:51 PM, Martin Sebor wrote:
On 03/17/2016 10:48 AM, Patrick Palka wrote:
On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law wrote:
On 03/16/2016 06:43 PM, Martin Sebor wrote:
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp
OK.
Jason
On Tue, Mar 15, 2016 at 03:41:52PM -0400, Jason Merrill wrote:
> Let's factor out that duplicated code into a separate function.
Sure. It also allowed me to hoist the cheap tests for both warnings, and
while at it, I used 'location' for the first warning.
Bootstrapped/regtested on x86_64-linux,
On Thu, Mar 17, 2016 at 12:27 PM, Jeff Law wrote:
> On 03/16/2016 06:43 PM, Martin Sebor wrote:
>>>
>>> @@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
>>> return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
>>> }
>>>
>>> +/* Possibly warn about an address nev
@@ -3974,6 +3974,38 @@ build_vec_cmp (tree_code code, tree type,
return build3 (VEC_COND_EXPR, type, cmp, minus_one_vec, zero_vec);
}
+/* Possibly warn about an address never being NULL. */
+
+static void
+warn_for_null_address (location_t location, tree op, tsubst_flags_t complain)
+{
..
Let's factor out that duplicated code into a separate function.
Jason
On Tue, Mar 15, 2016 at 11:56:18AM +0100, Jakub Jelinek wrote:
> From compile time perspective, I wonder if it wouldn't be better to do
> the cheap tests early, like:
> if (warn_address
> && (complain & tf_warning)
> && c_inhibit_evaluation_warnings == 0
> && !TR
On Tue, Mar 15, 2016 at 11:41:20AM +0100, Marek Polacek wrote:
> This is to fix missing "address of %qD will never be NULL" warning that went
> away since the delayed folding merge. The problem was that cp_build_binary_op
> was getting unfolded ops so in the constexpr case it saw "(int *) p" inste
14 matches
Mail list logo
