Is -Wparentheses b0rken in 3.3?

[Dave Korn]

> -----Original Message-----
> From: Paolo Carlini 
> Sent: 13 October 2004 11:58

> Dave Korn wrote:
> 
> >  This is with 3.3.3 (cygwin and mainline variants).
> >
> >  Is -Wparentheses supposed to catch these cases?  I could 
> file a bug.
> >Would anyone like to try it with HEAD?
> >  
> >
> HEAD behaves the same, and I think we do *not* want the 
> warning. See this thread:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01541.html

  Ah, thanks for the pointer!  In particular, I notice that in

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01545.html

Florian Weimer says 

" I think it should also be activated for "/=" at least (because this is
a comparison operator in other languages), maybe even for "<<=" and
">>=". "

which is just what I want it for.  "/=" is the VHDL equivalent of "!=", and
since I have a colleague here who has to write both C and VHDL, there's a
very real potential for confusion[*].  However, I see that it's arguable
both ways which way the warning should behave, and since the issue has been
addressed in PR17120, I won't bother filing a bug.  I will try and implement
it locally however.  Hmm, I see that for C it's detected by
c_common_truthvalue_conversion.

    case MODIFY_EXPR:
      if (warn_parentheses && C_EXP_ORIGINAL_CODE (expr) == MODIFY_EXPR)
	warning ("suggest parentheses around assignment used as truth
value");
      break;

  Am I right to assume that the reason this catches some MODIFY_EXPRs and
not others is in some way because of parser_build_binary_op clearing
C_EXP_ORIGINAL_CODE (or rather, _not_ setting it with a call to
C_SET_EXP_ORIGINAL_CODE)?

    cheers, 
      DaveK

[*]  Not just potential in fact, it just happened to him and caused a bit of
lost time debugging it, so it's very real.
-- 
Can't think of a witty .sigline today....