[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.