[PATCH] Remove non-portable tests from 20031003-1.c

[Roger Sayle <roger at eyesopen dot com>]

Mark asked me to investigate the failure of my testcase for PR opt/9325,
gcc.c-torture/execute/20031003-1.c, on ia64-hp-hpux11.22.  The failures
are the two tests f3 and f4, which were intended to check GCC's RTL-level
floating-point to integer constant folding.

The C and C++ standards state that the behaviour of overflow in real to
integer conversion is undefined.  Even so, these tests were to check that
such conversions at compile-time produced the "expected" results.

Further investigation reveals that this problem affects all ia64 targets,
not just hpux, and is caused by that architecture's instruction set.  The
Itanium doesn't have a float or double to 32-bit integer conversion, and
is therefore missing a fix_truncsfsi2 pattern.  Instead, it just has a
real to 64-bit "long" conversion, i.e. fix_truncsfdi2, provided by the
fcvt.fx.trunc.sf instruction.  The middle-end when generating RTL then
synthesizes the sequence float->64-bit long->32-bit int, that takes
advantage of C/C++'s undefined overflow.

In the 20031003-1.c f3 test case, 214783648 should overflow a 32-bit int
and produce a maximum representable value 214783647.  On the IA-64,
however, 21783648 is representable in 64 bits, which is then just
truncated to it's lower 32-bits, giving the value -214783648!  Doh!


This isn't a problem for Java, which when generating RTL creates its
own sequence to implement saturating semantics.  Notice also that on
IA-64, floating-point to integer conversion can generate any value on
overflow, so check for overflow after the fact becomes complicated.


My solution is to admit defeat and simply remove the non-portable tests
from 20031003-1.c.  There seems no point in slowing down IA-64 code by
requiring it to implement fix_trunc.fsi2 patterns.  Its quite within its
rights to define any overflow semantics it pleases, in which case its
not possible to portably check GCC's RTL-level FIX simplifications.  Its
often said that optimizations are difficult to test in GCC, and it looks
like this happens to be another instance of that adage.  The alternative
is to XFAIL the test on ia64-*-* and similar platforms.  Personally, I
think the test is more at fault than the Itanium architecture (just :).

Tested with a "make check-gcc" on i686-pc-linux-gnu.

Ok for mainline?


2003-10-13  Roger Sayle  <roger@eyesopen.com>

	* gcc.c-torture/execute/20031003-1.c: Remove non-portable tests
	for overflowing floating point to integer conversion during RTL
	simplification.


Index: 20031003-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20031003-1.c,v
retrieving revision 1.1
diff -c -3 -p -r1.1 20031003-1.c
*** 20031003-1.c	3 Oct 2003 21:33:57 -0000	1.1
--- 20031003-1.c	14 Oct 2003 02:01:25 -0000
*************** int f2()
*** 12,42 ****
    return (int)(float)(2147483647);
  }

- int f3()
- {
-   float a = 2147483648.0f;
-   return (int)a;
- }
-
- int f4()
- {
-   int a = 2147483647;
-   float b = (float)a;
-   return (int)b;
- }
-
  int main()
  {
    if (f1() != 2147483647)
      abort ();
    if (f2() != 2147483647)
      abort ();
- #ifdef __OPTIMIZE__
-   if (f3() != 2147483647)
-     abort ();
-   if (f4() != 2147483647)
-     abort ();
- #endif
    return 0;
  }

--- 12,23 ----

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833