Store motion related questions

[Daniel Berlin <dan at cgsoftware dot com>]

So after figuring out the main problem with the store motion patch
last night (expr_equiv_p would say that an alias set 0 mem, and an
alias set 1 mem, were not equivalent, and thus, we'd never test to see
if one killed the other), it's in good shape.
Except for one annoying thing.

On x86, i get the following fails (and these are the only fails):
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /home/users/d/db/dberlin/egcs/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/home/users/d/db/dberlin/egcs/gcc/testsuite/gcc.c-torture/compile/compile.exp
...
Running
/home/users/d/db/dberlin/egcs/gcc/testsuite/gcc.c-torture/execute/execute.exp
...
FAIL: gcc.c-torture/execute/930106-1.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/930106-1.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/980605-1.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/980605-1.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/conversion.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/conversion.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/cvt-1.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/cvt-1.c compilation,  -O3 -g
FAIL: gcc.c-torture/execute/gofast.c compilation,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/gofast.c compilation,  -O3 -g
Running
/home/users/d/db/dberlin/egcs/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp
...
Running
/home/users/d/db/dberlin/egcs/gcc/testsuite/gcc.c-torture/execute/memcheck/memcheck.exp
...
Running
/home/users/d/db/dberlin/egcs/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp
...
FAIL: gcc.c-torture/unsorted/round.c,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/unsorted/round.c,  -O3 -g
FAIL: gcc.c-torture/unsorted/conv.c,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/unsorted/conv.c,  -O3 -g


Notice these are all compilation failures.

We are crashing cc1 in real.c, line 4366:

  /* shift not more than 16 bits */
          eshift (xi, k);
        *i = (HOST_WIDE_INT) xi[M] & 0xffff;
        if (xi[0])
---->    *i = -(*i);


This leads me to a couple questions:
1. Why would these failures only, and consistently, happen at -O3.  Do we
not try to simplify floating point values at -O2?

2. Is the code in eifrac (the function containing the above code)
   correct and safe?

I just find it odd that this would be the only noticeable
miscompilation, such that the entire testsuite passes, except these
tests, which consistently fail only at a certain optimization level.

The stores it moves in eifrac do include stores around the above, but
what it's doing looks perfectly safe to me.
So i'm curious as to whether it's really some unsafe code in eifrac or
something, that is just being exposed by store motion.

Can anyone give me a clue here?


-- 
"I got my driver's license photo taken out of focus on purpose.
Now when I get pulled over the cop looks at it (moving it nearer
		and farther, trying to see it clearly)...  And says, "Here, you
can go."
"-Steven Wright