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
PR61271 showed that this warning, recently added to clang, is quite
useful and detected several reckless cases in the GCC codebase.
This patch adds this warning even for GCC. Due to PR61271,
it's not a part of -Wall, that would break the bootstrap, but
after that is fixed, I think we want this war
19 matches
Mail list logo
