RE: More on integer division
After a looking a little more, there seem to be other problems (including errors in my proposed solution). I don't know where the code for quotRem is, but it is also buggy. For instance, Prelude 9 `quotRem` (-5) (-1,4) (The correct answer is (-1,-4).) I'm frankly astonished: has noone used these functions with negative arguments before? GHC's answer looks right to me, since according to the report: (x `quot` y)*y + (x `rem` y) == x so (-1 * -5) + 4 == 9 but if 9 `rem` (-5) should be -4, then (-1 * -5) + -4 = 1 I'm shocked that non of the three Haskell implementations had a test suite that caught this problem. Take a look at fptools/testsuite/tests/ghc-regress/numeric/should_run/arith0011.hs. There may be one or two wrong answers lurking in there, but that's a lot of results to check by hand! Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
qualified instance declarations
Hi, GHC (5.03.20020410) wrongly accepts the following: :: C.lhs :: module C where class A a where a :: a - Int :: X.lhs :: module X where import qualified C instance C.A Int where C.a = id Note that the class method is qualified on the LHS which is not legal H98. --- Incidentally, I also noticed that GHC and Hugs behave differently for the following variant of X.lhs. :: X.lhs :: module X where import qualified C instance C.A Int where a = const X.a a = 4 GHC happily accepts the file while Hugs complains that ERROR X.lhs:6 - Type error in instance member binding *** Term : a *** Type : a - Integer *** Does not match : Int - Int There seems to be a difference in defaulting. [Don't ask me which is the correct behaviour.] The problem disappears if I supply an explicit type signature for `a'. Cheers, Ralf ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: qualified instance declarations
For those puzzled by the number of things called 'a' in Ralf's program, I'm attaching an alpha-renamed version. Removing the type signature (or changing the type signature to Integer) for a results in Ralf's type error in Hugs. It does indeed look as though Hugs applies defaulting to 'a' and comes up with the type Integer. Off the top of my head, I'd say this was correct since the default default is (Integer,Double). -- Alastair Reid module C where class B a where f :: a - Int module X where import qualified C instance C.B Int where f = const X.a a :: Int a = 4 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: qualified instance declarations
GHC (5.03.20020410) wrongly accepts the following: :: C.lhs :: module C where class A a where a :: a - Int :: X.lhs :: module X where import qualified C instance C.A Int where C.a = id This has been fixed, and GHC 5.04 will behave correctly. Incidentally, I also noticed that GHC and Hugs behave differently for the following variant of X.lhs. :: X.lhs :: module X where import qualified C instance C.A Int where a = const X.a a = 4 GHC happily accepts the file while Hugs complains that ERROR X.lhs:6 - Type error in instance member binding *** Term : a *** Type : a - Integer *** Does not match : Int - Int There seems to be a difference in defaulting. [Don't ask me which is the correct behaviour.] The problem disappears if I supply an explicit type signature for `a'. Hugs's defaulting behaviour differs from Haskell 98 (and always has done). See for example this discussion on the Haskell mailing list: http://www.haskell.org/pipermail/haskell/2002-May/009616.html (plus other messages with the same subject). Could someone from the Hugs camp please document this? Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: More on integer division
I'm shocked that non of the three Haskell implementations had a test suite that caught this problem. Take a look at fptools/testsuite/tests/ghc-regress/numeric/should_run/arith0011.hs. There may be one or two wrong answers lurking in there, but that's a lot of results to check by hand! Actually arith003 was the test I was thinking of, it covers more of the boundary cases than arith011. And indeed, having fixed divModInt#, there *were* several errors in the sample output from that test. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: GHC 5.03 CVS NT2000 Mingw32 - Possible profiling problem in rts/GC.c (or in gmp?)
Title: Message
I
doubt it.
Simon
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 29 June 2002 10:32To:
Simon Peyton-Jones; [EMAIL PROTECTED]Cc:
[EMAIL PROTECTED]Subject: Re: GHC 5.03 CVS NT2000 Mingw32 - Possible
profiling problem in rts/GC.c (or in gmp?)
Hi Simon.
No worries - I appreciate that it is an
enormous job for you guys.
As a matter of interest, would the fact that my
computer has an AMD K6 CPU rather than an Intel CPU be
relevant?
Cheers
Mike Thomas.
- Original Message -
From:
Simon
Peyton-Jones
To: Mike Thomas ; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, June 28, 2002 11:04
PM
Subject: RE: GHC 5.03 CVS NT2000
Mingw32 - Possible profiling problem in rts/GC.c (or in gmp?)
Mike
Your message has been sitting in my inbox for a
while.
GHC-compiled programs should never crash, but the combination of
profiling, object I/O, call backs, and the win32 platform makes a rather
complicated context for bug hunting.
Simon M is the profiling and run-time system expert, and he's not
well this week. Furthermore, he'd tied up trying to get 5.04 out of
the door. So I'm afraid you may not get much help from us for a
while.If anyone else can help, and if you find what's wrong,
that would be great. If you are still stuck on thisin a few
week's time, come back to us.
Simon
-Original Message-From: Mike Thomas
[mailto:[EMAIL PROTECTED]] Sent: 18 June 2002
14:38To: [EMAIL PROTECTED]Subject:
GHC 5.03 CVS NT2000 Mingw32 - Possible profiling problem in rts/GC.c (or
in gmp?)
Hi all.
I have a problemprofiling the
"hslibs/object-io/Examples/Bounce" example program.
When built with GHC 5.03 CVS (which was in
turn built with 5.02.3) using the default compiler and RTS Makefile
settings, the example runs, but roughly (pauses for GC and slower than the
pure Clean version).
To find the cause I tried building with
profiling turned on:
ghc Main.hs --make -package objectio -prof
-auto-all -o Bounce.exe -lopcodes
When run, the resulting executable crashes
with a requestor in:
__gmpn_divrem_2
divrem_2.c:151
Usingan RTS built with the default
debugging options found in "mk/built.mk.sample", I catch the exception
with DrMingw and get the stack dump shown in DEBUGGER OUT ONE (below) - an
access violation in line 3820 of "rts/GC.c"
(get_itbl(frame)-type).
Ithen inserted a "#undef DEBUG" in
"rts/GC.c".
This just pushes the crash to the next
reference to the sameconstruct - line 3841. See DEBUGGER OUT
TWO - also below. This time there is also a reference to the same
gmp routine as above, which for some reason is not reported in DEBUGGER
OUT ONE.
Any help on interpreting and squishing this
one gratefully accepted.
Cheers
Mike Thomas.
=
DEBUGGER OUT ONE - DEBUG defined in GC.c
=
Bounce.exe caused an Access Violation at
location 0056349d in module Bounce.exe Reading from location
000d.
Registers:eax=101c031c ebx=101c0400
ecx=000d edx=000d esi=101c031c edi=101c23e8eip=0056349d
esp=0022dd88 ebp=0022ddd0
iopl=0 nv up ei pl zr na
po nccs=001b ss=0023 ds=0023 es=0023
fs=0038
gs=
efl=0246
Call stack:0056349D
Bounce.exe:0056349D threadSqueezeStack
GC.c:3820... frame,
prev_frame);
}) switch (get_itbl(frame)-type)
{ case
UPDATE_FRAME:upd_frames++;...
0056378B Bounce.exe:0056378B
threadPaused GC.c:4054...{ if (
RtsFlags.GcFlags.squeezeUpdFrames == rtsTrue
) threadSqueezeStack(tso);// does black
holing too else
threadLazyBlackHole(tso);...
00554592 Bounce.exe:00554592
suspendThread Schedule.c:1532...
threadPaused(cap-r.rCurrentTSO);
cap-r.rCurrentTSO-link =
suspended_ccalling_threads; suspended_ccalling_threads =
cap-r.rCurrentTSO;...
004795A9
Bounce.exe:004795A900A749D024448904
=
DEBUGGER OUTTWO - DEBUG UNdefined in GC.c
=
Bounce.exe caused an Access Violation at location 00684c7d in module
Bounce.exe Reading from location .
Registers:eax=101bf3f4 ebx=006ab3d0
Re: More on integer division
However, it's easy to write a program to verify such results,
assuming you trust your addition and multiplication and comparisons:
[...]
Also, looking at arith003, there are a few more test cases I might
include, with quotient/remainder, say, 3/4 or 1/2 of maxInt. You
also don't seem to test arithmetic with large negative operands in
the cases I saw.
Send us improved testsuites and we'll happily add them to our suites.
The most relevant Hugs testsuites are:
intTest.{hs,input,output}
in
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/tests/libs/
and (somewhat lamer):
arith.{hs,input,output}
maxint.{hs,input,output}
in
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/tests/rts/
Best bet is to cvs checkout hugs98 (we exclude the testsuite from
distributions) and follow the instructions in hugs98/tests/Readme
--
Alastair Reid
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
