> -----Original Message-----
> From: Mikael Pettersson [mailto:mi...@it.uu.se]
> Sent: 04 May 2013 11:51
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: BImode and STORE_VALUE_FLAG
>
> I can't comment on the code in question, but the backend for m68k may be
> affected
> since it defines STORE_FLAG_VALUE as -1. Do you have a testcase that would
> cause
> wrong code, or a patch to cure the issue? I'd be happy to do some testing on
> m68k-linux.
>
Mikael,
Still related to this issue, I think I found a bug that affects m68k due to the
use of STORE_FLAG_VALUE != 1.
Try the following example (this is a trimmed down version of vector-compare-1.c
from gcc testsuite):
int main (int argc, char *argv[]) {
int i, ires;
volatile int i0 = 2;
volatile int i1 = 2;
ires = (i0 >= i1);
if (ires != (i0 >= i1 ? -1 : 0)) {
__builtin_printf ("%i != ((" "%i" " " ">=" " " "%i" " ? -1 : 0) ",
(ires), (i0), (i1));
return 1;
}
return 0;
}
I haven't tried to run it in m68k-linux since I don't have binutils-m68k
installed but I assume it will print something like:
-1 != ((2 >= 2 ? -1 : 0)
and return exit code 1.
I did run m68k cc1 (gcc-4.7.3) and dumped logs and found the problem (which
matches what I am seeing with my port).
We get to vrp1 with:
D.1392_5 = i0.0D.1390_3 >= i1.1D.1391_4;
iresD.1386_6 = (intD.1) D.1392_5;
# VUSE <.MEMD.1405_18>
i0.3D.1394_7 ={v} i0D.1387;
# VUSE <.MEMD.1405_18>
i1.4D.1395_8 ={v} i1D.1388;
if (i0.3D.1394_7 >= i1.4D.1395_8)
goto <bb 4>;
else
goto <bb 3>;
# SUCC: 4 [50.0%] (true,exec) 3 [50.0%] (false,exec)
# BLOCK 3 freq:5000
# PRED: 2 [50.0%] (false,exec)
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:10000
# PRED: 2 [50.0%] (true,exec) 3 [100.0%] (fallthru,exec)
# iftmp.2D.1393_1 = PHI <-1(2), 0(3)>
if (iftmp.2D.1393_1 != iresD.1386_6)
goto <bb 5>;
else
goto <bb 6>;
# SUCC: 5 [62.2%] (true,exec) 6 [37.8%] (false,exec)
The important bits are:
D.1392_5 = i0.0D.1390_3 >= i1.1D.1391_4;
iresD.1386_6 = (intD.1) D.1392_5;
...
# iftmp.2D.1393_1 = PHI <-1(2), 0(3)>
if (iftmp.2D.1393_1 != iresD.1386_6)
goto <bb 5>;
else
goto <bb 6>;
vrp1 will then proceed to find the ranges for D.1392_5 = i0.0D.1390_3 >=
i1.1D.1391_4;
Since this is a comparison set_value_range_to_truthvalue is called and returns
the range [0, 1].
Then vrp1 simplifies the phi node to iftmp.2D.1393_1 = PHI < 0 > since -1 is
not within the range.
From hereon a couple of simplifications break the remainder of the cgraph and
generates incorrect code.
Can you reproduce this?
Cheers,
Paulo Matos
