Bug in real.c rewrite

Bug in real.c rewrite

[law]

The real.c rewrite that went into the tree in September has at least
one buglet left.


Consider this test (derived from conversion.c):

main()
{
  if (((unsigned long long int)((float) ~((~0ULL) >> 1))) != 
0x8000000000000000ULL)
    abort();
  exit (0);
}

The problem is the RHS of the comparison is computed as 0x7fffffffffffffff
rather than 0x8000000000000000.  This (of course) causes the test to
fail.  It works fine with a compiler from just before the rewrite.


Jeff

Re: Bug in real.c rewrite

[Richard Henderson]

On Mon, Feb 24, 2003 at 05:33:01PM -0700, law@redhat.com wrote:
>   if (((unsigned long long int)((float) ~((~0ULL) >> 1))) != 
> 0x8000000000000000ULL)

Not a bug in real.c; fold_convert is failing to mention
that we're converting back to *unsigned* LL.  I'll work
on a fix.


r~

Re: Bug in real.c rewrite

[Richard Henderson]

On Tue, Feb 25, 2003 at 10:45:13AM -0800, Richard Henderson wrote:
> On Mon, Feb 24, 2003 at 05:33:01PM -0700, law@redhat.com wrote:
> >   if (((unsigned long long int)((float) ~((~0ULL) >> 1))) != 
> > 0x8000000000000000ULL)
> 
> Not a bug in real.c; fold_convert is failing to mention
> that we're converting back to *unsigned* LL.  I'll work
> on a fix.

Ho hum.  There actually _isn't_ a way to indicate signed or unsigned
during the conversion.

I recall now that this form of overflow is something that Alan Modra
talked me into at the time.  I'm now thinking that this is more trouble
that it's worth, trying to force a particular result for a value that's
technically undefined.  So I've reverted the change.


r~


        * real.c (real_to_integer2): Force overflow result only for 
        unsigned overflow.

Index: real.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/real.c,v
retrieving revision 1.109
diff -c -p -d -u -r1.109 real.c
--- real.c	27 Jan 2003 06:23:32 -0000	1.109
+++ real.c	25 Feb 2003 21:33:58 -0000
@@ -1371,7 +1371,7 @@ real_to_integer2 (plow, phigh, r)
       exp = r->exp;
       if (exp <= 0)
 	goto underflow;
-      if (exp >= 2*HOST_BITS_PER_WIDE_INT)
+      if (exp > 2*HOST_BITS_PER_WIDE_INT)
 	goto overflow;
 
       rshift_significand (&t, r, 2*HOST_BITS_PER_WIDE_INT - exp);

Re: Bug in real.c rewrite

[Neil Booth]

Richard Henderson wrote:-

> I recall now that this form of overflow is something that Alan Modra
> talked me into at the time.  I'm now thinking that this is more trouble
> that it's worth, trying to force a particular result for a value that's
> technically undefined.  So I've reverted the change.

If something's contraversial there, could I suggest you add an
explanatory comment?  Otherwise it's the kinda thing that gets changed
again 2 years down the line when everyone's forgotten the issues.

Neil.

Re: Bug in real.c rewrite

[law]

In message <20030225230552.GD13285@redhat.com>, Richard Henderson writes:
 >Ho hum.  There actually _isn't_ a way to indicate signed or unsigned
 >during the conversion.
 >
 >I recall now that this form of overflow is something that Alan Modra
 >talked me into at the time.  I'm now thinking that this is more trouble
 >that it's worth, trying to force a particular result for a value that's
 >technically undefined.  So I've reverted the change.
 >
 >
 >r~
 >
 >
 >        * real.c (real_to_integer2): Force overflow result only for 
 >        unsigned overflow.
Thanks.  That fixes the execute/conversion.c and ieee/rbug.c failures
on the tree-ssa branch :-)

jeff

Re: Bug in real.c rewrite

[Alan Modra]

On Tue, Feb 25, 2003 at 03:05:52PM -0800, Richard Henderson wrote:
> I recall now that this form of overflow is something that Alan Modra
> talked me into at the time.

I did?  Hmm, must have been when I was trying to make real -> int
conversions peg at min/max representable int rather than wrapping.
That patch never went in due to lack of review.  :-(

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Bug in real.c rewrite

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

| Richard Henderson wrote:-
| 
| > I recall now that this form of overflow is something that Alan Modra
| > talked me into at the time.  I'm now thinking that this is more trouble
| > that it's worth, trying to force a particular result for a value that's
| > technically undefined.  So I've reverted the change.
| 
| If something's contraversial there, could I suggest you add an
| explanatory comment?  Otherwise it's the kinda thing that gets changed
| again 2 years down the line when everyone's forgotten the issues.

Seconded.

-- Gaby