This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix PR 19643. [ Was Re: Speedup CSE by 5% ]
- From: Roger Sayle <roger at eyesopen dot com>
- To: Jeffrey A Law <law at redhat dot com>
- Cc: jakub at redhat dot com, <bernds_cb1 at t-online dot de>, <arend dot bayer at web dot de>, <richard dot guenther at gmail dot com>, <gcc-patches at gcc dot gnu dot org>, <kenner at vlsi1 dot ultra dot nyu dot edu>
- Date: Fri, 28 Jan 2005 09:27:42 -0700 (MST)
- Subject: Re: Fix PR 19643. [ Was Re: Speedup CSE by 5% ]
Hi Jeff,
On Fri, 28 Jan 2005, Jeffrey A Law wrote:
> On Thu, 2005-01-27 at 18:33 -0500, Kazu Hirata wrote:
> > In case you wonder where three occurrences in the MINUS case come
> > from, I've filed a PR 19643.
>
> This fixes PR 19643 in the obvious way.
Alas, not so "obvious" as this is clearly incorrect.
>! /* 0 % X is always zero as is X % 1. */
>! if (integer_zerop (arg0) || integer_onep (arg1))
> return omit_one_operand (type, integer_zero_node, arg0);
If the first argument is integer_zerop, then its the second operand
arg1 that needs to be evaluated for potential side-effects before
returning zero.
i.e. something closer might be
if (integer_onep (arg1))
return omit_one_operand (type, integer_zero_node, arg0);
if (integer_zerop (arg0))
return omit_one_operand (type, integer_zero_node, arg1);
We should add a "0 % x++" testcase to the testsuite (if there isn't
one already). p.s. don't forget to list the target-triple that you
bootstrap and regression test on when you post a correction.
I'm still investigating possible java front-end interactions and
whether gcj/bytecode requires the evaluation of "0 % 0" to throw
a java.lang.ArithmeticException.
Roger
--