http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-07
16:34:14 UTC ---
Ah, ok, seems indeed to be HWI size related and also (due to an earlier bug)
related to the revision you've mentioned.
So, with an i686-linux -> hppa2.0w-hp-hpux11.11 cross this is reproduceable
with -O2 on:
extern unsigned int *kiss_seed_1;
extern unsigned int *kiss_seed_2;
unsigned int kiss_random_kernel(unsigned int * seed);
void
foo (double *x)
{
unsigned long long mask, kiss = ((unsigned long long) kiss_random_kernel
(kiss_seed_1)) << 32;
kiss += kiss_random_kernel (kiss_seed_2);
mask = ~ (unsigned long long) 0u << (64 - 53);
kiss = kiss & mask;
*x = (double) kiss * (0x1.p-64);
}
and the problem is that starting with r189366 VRP incorrectly does:
kiss_9 = kiss_8 & 0xfffffffffffff800;
- D.1358_10 = (double) kiss_9;
+ D.1363_17 = (signed int) kiss_9;
+ D.1358_10 = (double) D.1363_17;
The bugs seem to be in simplify_float_conversion_using_ranges and
range_fits_type_p. The simplify_float_conversion_using_ranges bug (now just
code consistency issue, before r189366 a real bug) is that the second
can_float_p is tested for != 0 (implicitly) instead of != CODE_FOR_nothing.
Starting with r189366 it doesn't make a real difference, before that
CODE_FOR_nothing was some big number and this fact hid the other bug.
>From the kiss_9 assignment, VRP determines vr to be
[0, 0xfffffffffffff800]
(in unsigned long long type).
And now the bug is that while range_fits_type_p (vr, 8, 0) and
range_fits_type_p (vr, 64, 0) correctly return false, such big 64-bit range
really doesn't fit into signed 8-bit or signed 64-bit range,
range_fits_type_p (vr, 16, 0) and range_fits_type_p (vr, 32, 0) incorrectly
return true - and for floatsidf2 there is a pattern, which is why we miscompile
it.
