On Mon, 23 Jun 2014, Marek Polacek wrote:
> I think the latter is better, incidentally, g++ doesn't warn either.
> The following one liner makes cc1 behave as cc1plus. Thanks for the
> report.
>
> Regtested/bootstrapped on x86_64. Joseph, is this ok?
>
> 2014-06-23 Marek Polacek
>
>
On Sun, Jun 22, 2014 at 10:33:57PM +0200, Gerald Pfeifer wrote:
> On Mon, 2 Jun 2014, Marek Polacek wrote:
> > * c-typeck.c (parser_build_binary_op): Warn when logical not is used
> > on the left hand side operand of a comparison.
>
> This...
>
> > +/* Warn about logical not used on the
On Mon, 2 Jun 2014, Marek Polacek wrote:
> * c-typeck.c (parser_build_binary_op): Warn when logical not is used
> on the left hand side operand of a comparison.
This...
> +/* Warn about logical not used on the left hand side operand of a comparison.
...and this...
> + warning_at (
On Wed, Jun 04, 2014 at 10:47:34PM +, Joseph S. Myers wrote:
> On Mon, 2 Jun 2014, Marek Polacek wrote:
>
> > +@smallexample
> > +int a;
> > +...
> > +if (!a > 1) @{ ... @}
>
> @dots{}, since this is an ellipsis not the literal ... token.
Fixed (and on the other spot in -Wswitch-bool paragra
On Mon, 2 Jun 2014, Marek Polacek wrote:
> +@smallexample
> +int a;
> +...
> +if (!a > 1) @{ ... @}
@dots{}, since this is an ellipsis not the literal ... token.
--
Joseph S. Myers
jos...@codesourcery.com
OK.
Jason
On Wed, Jun 04, 2014 at 11:02:10PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 04, 2014 at 10:56:43PM +0200, Marek Polacek wrote:
>
> > +/* Warn about logical not used on the left hand side operand of a
> > comparison.
> > + This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
> > +
On Wed, Jun 04, 2014 at 10:56:43PM +0200, Marek Polacek wrote:
> +/* Warn about logical not used on the left hand side operand of a comparison.
> + This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
> + Do not warn if the LHS or RHS is of a boolean or a vector type. */
> +
> +voi
On Mon, Jun 02, 2014 at 01:50:53PM -0400, Jason Merrill wrote:
> On 06/02/2014 01:04 PM, Marek Polacek wrote:
> >>>#ifdef __cplusplus
> >>>template bool f(T t, U u) { return (!t == u); }
> >>>#endif
> >>>
> >>>I think !t should have null TREE_TYPE in this case.
> >
> >Hmm, I see no crash; the type
On 06/02/2014 01:04 PM, Marek Polacek wrote:
#ifdef __cplusplus
template bool f(T t, U u) { return (!t == u); }
#endif
I think !t should have null TREE_TYPE in this case.
Hmm, I see no crash; the types seem to be
template_type_parm 0x7013d5e8 T type_0 type_6 VOID ...
Right, because you'
On Mon, Jun 02, 2014 at 07:04:58PM +0200, Marek Polacek wrote:
> > Do we actually want to warn in that case? As the patch doesn't warn
> > if the type is bool or vector, if somebody instantiates the above with
> > say T=bool, U=bool, then we'd warn on something that otherwise will not be
> > warne
On Mon, Jun 02, 2014 at 06:36:06PM +0200, Jakub Jelinek wrote:
> On Mon, Jun 02, 2014 at 12:31:32PM -0400, Jason Merrill wrote:
> > On 06/02/2014 12:23 PM, Marek Polacek wrote:
> > >I have no special reason for that check, so dropped it too in this
> > >patch.
> >
> > Thanks. I expect that warn_lo
On Mon, Jun 02, 2014 at 12:31:32PM -0400, Jason Merrill wrote:
> On 06/02/2014 12:23 PM, Marek Polacek wrote:
> >I have no special reason for that check, so dropped it too in this
> >patch.
>
> Thanks. I expect that warn_logical_not_parentheses will crash if one
> of the operands is type-dependent
On 06/02/2014 12:23 PM, Marek Polacek wrote:
I have no special reason for that check, so dropped it too in this
patch.
Thanks. I expect that warn_logical_not_parentheses will crash if one of
the operands is type-dependent such that TREE_TYPE is NULL_TREE, so
you'll want to handle that case, a
On Mon, Jun 02, 2014 at 12:01:22PM -0400, Jason Merrill wrote:
> On 06/02/2014 11:17 AM, Marek Polacek wrote:
> >+ && !processing_template_decl
>
> Also, why not warn when parsing a template? We don't need to know the type
> to recognize the problematic syntax.
I have no special reason for
On 06/02/2014 11:17 AM, Marek Polacek wrote:
+ && !processing_template_decl
Also, why not warn when parsing a template? We don't need to know the
type to recognize the problematic syntax.
Jason
On Mon, Jun 02, 2014 at 10:08:24AM -0400, Jason Merrill wrote:
> On 06/02/2014 02:50 AM, Marek Polacek wrote:
> >+ && TREE_CODE (arg1.value) == EQ_EXPR)
> ...
> >+ && TREE_CODE (current.lhs) == EQ_EXPR
>
> It seems like your version only warns about ==, while the clang version
> warns ab
On 06/02/2014 02:50 AM, Marek Polacek wrote:
+ && TREE_CODE (arg1.value) == EQ_EXPR)
...
+ && TREE_CODE (current.lhs) == EQ_EXPR
It seems like your version only warns about ==, while the clang version
warns about all comparisons.
+ && (complain_flags (decltype_p) & tf
18 matches
Mail list logo
