This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: CVS Update: www.netwinder.org: pub
- To: law at cygnus dot com
- Subject: Re: CVS Update: www.netwinder.org: pub
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Thu, 2 Sep 99 06:42:16 EDT
- Cc: gcc-patches at gcc dot gnu dot org
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.