Re: CVS Update: www.netwinder.org: pub

[Jeffrey A Law <law at cygnus dot com>]

  In message <9909021042.AA21725@vlsi1.ultra.nyu.edu>you write:
  >     This bug has existed in gcc-2.8.x, egcs-1.0.x, egcs-1.1.x gcc-2.95.x
  >     :( I'll put it in the potential queue for gcc-2.95.2.
  > 
  >     It turns out to be a simple bug.  The compiler has code to try and opti
  > mize
  >     range tests.
  > 
  >     Basically we had
  > 
  >     (ANDIF (EQ X 0) (EQ X 1))
  > 
  >     The compiler realized that there is no value of X in which that express
  > ion
  >     can ever be true.  
  > 
  >     But it forgot to take into account volatile :-)
  > 
  >     This bug has existed in every gcc/egcs release after gcc-2.7.x.  Wow.
  > 
  > That's odd.  Look at the following code in operand_equal_p:
  > 
  >   /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.
  >      We don't care about side effects in that case because the SAVE_EXPR
  >      takes care of that for us. In all other cases, two expressions are
  >      equal if they have no side effects.  If we have two identical
  >      expressions with side effects that should be treated the same due
  >      to the only side effects being identical SAVE_EXPR's, that will
  >      be detected in the recursive calls below.  */
  >   if (arg0 == arg1 && ! only_const
  >       && (TREE_CODE (arg0) == SAVE_EXPR
  > 	  || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1))))
  >     return 1;
  > 
  > Why didn't that prevent the bug?  Doing it the way you did would not
  > allow two identical SAVE_EXPRs to be considered equal, and they should be.
The operands were not strictly equal.  ie arg0 != arg1

jeff