This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


    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 optimize
    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 expression
    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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]