[M3devel] bugs in hand.c division

[Jay K]

Actually there is also a problem passing 64 bit integers to K&R functions.

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:57:55 +0000
Subject: Re: [M3devel] bugs in hand.c division








The gcc-4.2 -O2 case is for LONG_MIN / -1, which overflows.
What is that supposed to equal?
For any version that doesn't "crash", the result is LONG_MIN.

 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:48:42 +0000
Subject: Re: [M3devel] bugs in hand.c division








(Of course I'll have to look into the mod functions as well. :) )

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:46:09 +0000
Subject: Re: [M3devel] bugs in hand.c division








The -101/1 thing, I just had the parameters reversed.

However there are at least two classes of bugs in m3_div and m3_divL.


1) They return the result with the wrong sign sometimes, as shown.

2) gcc 4.2 -O2 on my Mac causes the existing functions to raise
a signal, presumably divide by zero, where without -O2 does not.

I'll be fixing both shortly, and including test code.
The test code will show that without optimization, I get the same
results for various inputs, except that I fix the sign sometimes.
Similar with gcc 4.0.1 -O2.
This is all on Darwin/x86.
I'll test out some other variations.
This will also fix the warnings under -O2 -Wstrict-overflow=4 or such.


 - Jay

From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sun, 17 Jan 2010 05:10:10 +0000
Subject: [M3devel] bugs in hand.c division








The division functions in hand.c sometimes have the wrong sign on the result.

jbook2:Common jay$ ./a.out
-2147483648 / -2147483647 = old:-1, new:1
-2147483648 / -1073741824 = old:-2, new:2
-2147483648 / -1073741823 = old:-2, new:2
-2147483648 / -1073741825 = old:-1, new:1
-2147483648 / -10 = old:-214748364, new:214748364
-2147483648 / -9 = old:-238609294, new:238609294
-2147483648 / -8 = old:-268435456, new:268435456
-2147483648 / -7 = old:-306783378, new:306783378
-2147483648 / -6 = old:-357913941, new:357913941
-2147483648 / -5 = old:-429496729, new:429496729
-2147483648 / -4 = old:-536870912, new:536870912
-2147483648 / -3 = old:-715827882, new:715827882
-2147483648 / -2 = old:-1073741824, new:1073741824

I'll be fixing this shortly.
It occurs without any optimizations.

There is another bug I don't understand yet.
m3_divL(101/-1) is -1 but m3_div(101/-1) is the correct -101.

I think I'm also seeing optimization alter the results
but I have to look closer.

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100117/c7bd059e/attachment-0002.html>