[ ghc-Bugs-630807 ] -O2 generates wrong code
Bugs item #630807, was opened at 2002-10-30 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 Category: Compiler Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Peyton Jones (simonpj) Summary: -O2 generates wrong code Initial Comment: I have a program (the Bluespec compiler), where using -O2 generates a program that loops (or at least is VERY slow), whereas not using generates a working program. I can't really give you the source code, but perhaps you can contact me and we can see if we can work something out. -- Lennart [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 10:47 Message: Logged In: YES user_id=48280 Fixed in rev. 1.140 of Simplify.lhs, fix will be in 5.04.3 (if we release it). -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-30 18:31 Message: Logged In: NO Further investigations show that the generated code is not looping, it is indeed correct, but it's just been incredibly pessimised. On a smaller example the unoptmized code finishes in 0.02s and the optmized code in 18s. It seem that the complexity of the (very complicated) algorithm has suddenly become exponential with -O2. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-30 00:14 Message: Logged In: NO BTW, this bug is in 5.02 too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-653009 ] com. line args not honoured for recompil
Bugs item #653009, was opened at 2002-12-12 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: com. line args not honoured for recompil Initial Comment: I compiled a file with a standard compile and link and some flags, include -fallow-overlapping-isntances. I was interested in whether overlapping instances were really required, so I recompiled -- without modifying the file -- without -fallow-overlapping-instances. I got the compilation IS NOT required message, clearly erroneous. Suggestion: flag configuration / compiler state stored in generated code and checked on recompile. My email is [EMAIL PROTECTED] Thanks, Nick -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 11:07 Message: Logged In: YES user_id=48280 Yes, but (a) make doesn't know that you've changed the options, (b) sometimes you want to change options without recompiling, eg. adding/removing -O, etc. and (c) it's extra work for us to implement :-) Workaround: use -no-recomp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
mkIOError
According to the FFI spec, this should have type IOErrorType - String - Maybe FilePath - Maybe Handle - IOError but System.IO.Error has the last two arguments in the other order. I think the spec is right, because that matches the order for annotateIOError. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-652927 ] Integer - Int64 sometimes wrong
Bugs item #652927, was opened at 2002-12-12 21:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 Category: hslibs/lang Group: 5.04.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Simon Marlow (simonmar) Summary: Integer - Int64 sometimes wrong Initial Comment: Conversion from Integer to Int64 values sometimes produces the wrong value. In particular, it seems to fail on small-magnitude negative values whose representation is large. E.g. (fromIntegral ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer))) :: Data.Int.Int64 4294967295 (fromIntegral ((2^30 - 2 + 2^30) - (2^30 - 1 + 2^30 :: Integer))) :: Data.Int.Int64 -1 The Haskell-level workaround is to do the conversion as a non-negative number then negate if needed: let fis (i::Integer) = (fromIntegral (signum i) * fromIntegral (abs i)) :: Data.Int.Int64 fis ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer)) -1 -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 14:26 Message: Logged In: YES user_id=48280 Fixed; thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-651842 ] Link failure with -prof (OS X, CVS GHC)
Bugs item #651842, was opened at 2002-12-11 06:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: whee (whee) Assigned to: Nobody/Anonymous (nobody) Summary: Link failure with -prof (OS X, CVS GHC) Initial Comment: Using Mac OS X 10.2.2, the linker fails when -prof is in effect: (Relevant output from 'ghc -v -prof --make file.hs -o file') ld -arch ppc -dynamic -framework HaskellSupport [snip] -o file -lcrt1.o -lcrtbegin.o -L/usr/local/lib/ghc-5.05 -L/usr/lib/gcc/darwin/3.1 -L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.1/../../.. file.o -lHShaskell98_p -lHSbase_p -lHSbase_cbits -lHSrts_p -lm -lpthread -lgcc -lSystem | c++filt3 ld: Undefined symbols: _TextziReadziLex_Char_con_info Upon further inspection, the symbol _TextziReadziLex_Char_con_info is indeed not defined in libHSbase_p.a as it should be. It is, however, present in libHSbase.a. After a full clean and rebuild, the problem persists. This is with GHC 5.05 (CVS 2002-12-11). -- Comment By: Wolfgang Thaller (wthaller) Date: 2002-12-13 19:42 Message: Logged In: YES user_id=566359 No problem here (CVS 2002-12-12). Both libHSbase.a and libHSbase_p.a contain the symbol TextziReadziLex_Char_con_info. No error occurs when linking a hello-world style program for profiling. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC Undefined
If you're mixing code compiled and linked with different versions of binutils / gcc, then you're pretty much on your own - i.e., I'm assuming you didn't build pdcurses via 'ghc' but 'gcc' 'ld'/'dllwrap'. --sigbjorn - Original Message - From: michael vorin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 14:13 Subject: GHC Undefined Whilst I was trying to get the curses binding example in QForeign to compile - I stumbled on what I believe to be a bug. Essentialy I believe that the version of ld.exe that you have packaged up with ghc 5.04 win32 has a bug or is perhaps badly configured. ghc uses - GNU ld version 2.11.90 (20010704) (with BFD 2.11.90) which did not properly resolve external references to variables (see below). I resolved problem by using - GNU ld version 2.13, from current mingw release. my configuration GHC 5.04 Win32 running on win2K platform. What I encountered ghc -fglasgow-exts CursesTest.hs CursesTest_hsc.c Curses.hs curses_hsc.c -lpdcurses curses_hsc.o(.text+0x4):curses_hsc.c: undefined reference to `stdscr' curses_hsc.o(.text+0x10):curses_hsc.c: undefined reference to `LINES' curses_hsc.o(.text+0x1c):curses_hsc.c: undefined reference to `COLS' curses_hsc.o(.text+0x28):curses_hsc.c: undefined reference to `COLOR_PAIRS' curses_hsc.o(.text+0x34):curses_hsc.c: undefined reference to `COLORS' when I had a look at the object files and the libpdcurses.dll, the appropriate symbols were in fact defined, and in fact all functions were resolved, the above symbols represent bindings to variables declared as follows:- extern int LINES; 2. setup of a test - I setup a test (test.c attached) where I just had one external reference that I was trying to resolve. I compiled it curses\tst-linesghc tst.c -o tst.exe -lpdcurses tst.o(.text+0x4):tst.c: undefined reference to `LINES' curses\tst-linesgcc tst.c -o tst.exe -lpdcurses Info: resolving _LINES by linking to __imp__LINES (auto-import) the above should give the same result, i.e. the later result 3. fix I copied ld.exe from my mingw release (version 2.13) over ld.exe in the ghc release (version 2.11.90 ). This solved my problem 4. postmortem - why the problem ? Does this problem occur with all external variable references or is limitted to a few dll libraries, does it occur linking against static libraries ? I don't know _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Porting mips-sgi-irix65 [help]
Box : mips-sgi-irix65 Version : 4.08.2 Unregisterised ( using mini-interpreter) Source File : nfibI.hc ( compiled on a running box i386-unknown-linux ) -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-manling -funregistered -fvia-C -C Traced File : ghc/rts/GC.c ( Garbage collector ) References : ghc/includes/Closures.h,ClosureTypes.h,ClosureMacros.h Implementing lazy functional Lan... [Peyton Jones] Session: bash-2.04$ ghc -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregistered -fvia-C nfibI.hc -o nfibI bash-2.04$ ./nfibI --run in irix nfibI: fatal error: evacuate: strange closure type 4137 bash-2.04$ ./nfibI --run in linux 2692537 Linux closure-type sequence:Irix closure-type sequence: = 59 (TSO)59 59 59 59 59 10 (CONST_NOCAF_STATIC) 10 10 10 33 (IND_STATIC)4137 (zzz! Max number 64 !) 17 (FUN_STATIC) 33 17 33 29 Why these special types (33,17) crash ? Where is the info-type stored ? Is IRIX closure representation-allignment faulty (char vs int )? -.....- | | | | info-pointer | pointer-words | non-pointer words | | | -..-...- Any suggestions to go on hacking ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Porting mips-sgi-irix65 [help]
Box : mips-sgi-irix65 Version : 4.08.2 Unregisterised ( using mini-interpreter) Source File : nfibI.hc ( compiled on a running box i386-unknown-linux ) -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-manling -funregistered -fvia-C -C Traced File : ghc/rts/GC.c ( Garbage collector ) References: ghc/includes/Closures.h,ClosureTypes.h,ClosureMacros.h Implementing lazy functional Lan... [Peyton Jones] Session: bash-2.04$ ghc -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -fno-asm-mangling -funregistered -fvia-C nfibI.hc -o nfibI bash-2.04$ ./nfibI--run in irix nfibI: fatal error: evacuate: strange closure type 4137 bash-2.04$ ./nfibI--run in linux 2692537 Linux closure-type sequence: Irix closure-type sequence: = 59 (TSO) 59 5959 5959 10 (CONST_NOCAF_STATIC) 10 1010 33 (IND_STATIC) 4137 (zzz! Max number 64 !) 17 (FUN_STATIC) 33 17 33 29 Something is wrong with the heap layout perhaps, or maybe the info tables. I can't tell much more from the information above; you'll need to fire up gdb on the executable and dig into the contents of the heap and info tables at the point of the crash. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Constant space infinite itteration ... solution?
I'm trying to write a non trivial gui in Haskell. At the moment I'm using Hugs, and rapidly coming to the conclusion that I should be using something else such as GHC. I've written GUIs and other reactive systems with Hugs and GHC which did not leak space and, since the bulk of the work was done by X or Win32 (i.e., standard library code written in C), ran fast enough to keep up with humans. I doubt that GHC's speed and optimizations will fix your problems. As I see it the problem is basically that of tail recursion removal or as David Bergman calls it last call optimisation. I suspect this may be a red herring. Space leaks in Haskell are most often caused by hanging onto unevaluated expressions or by accidentally hanging onto data that should be garbage. You should use a heap profiler to identify the true cause of your space leaks and then go fix those. GHC and NHC both contain good heap profilers. GHC contains libraries that are most similar to Hugs. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Constant space infinite itteration ... solution?
Hi, Bruce.
Just want to clarify the last call optimisation/tail recursion
terminology.
One does not remove a tail recursive call, one just make it O(1)
w.r.t. stack (or any other where have we been call frame structure...)
with the help of tail recursion optimisation. Last call optimisation
is a generalization of the latter optimisation, applicable to any call,
recursive or not.
In effect, implementers seldom care whether the last call is recursive
or not, they just skip the return address pushing, making last call
optimisation operationally equivalent to tail recursion optimisation.
Richard was (and still is) completely correct in that last call
optimisation is not a crucial element in lazy evaluation, although that
is not necessarily true when strictness analysis or explicit strictness
annotations (!) allow the implementation to skip the general thunk
creation/inspection/destruction loop and instead use the much more
time-efficient eager evaluation (i.e., mapping to the C code you
referred to...), which can be memory-inefficient, similar to your Hugs
experience.
Good luck with that Ferrari (that is the only Ferrari we Haskellers will
ever see...)
/David
Bruce wrote:
Hi all,
Ok, I've got the Farari out of the garage, in to gear, and even driven
it slowly around the block, but every time I put my foot down it just
stalls.
I'm trying to write a non trivial gui in Haskell. At the
moment I'm using Hugs, and rapidly coming to the conclusion
that I should be using something else such as GHC.
As I see it the problem is basically that of tail recursion
removal or as David Bergman calls it last call optimisation.
Specifically:
David Bergman wrote
It is easy to get the feeling that the recursive call in
recurse = do { f x ; recurse }
is the last one, but this is just an illusion of the iterative
layout of do. Sometimes the monads lure us into old iterative
thought patterns...
Taking away the syntactic sugar, we end up with
recurse = f x recurse
This reveals the fact that there can be no last call optimization,
because the last call is .
In response Richard Uhtenwoldt echoed my own thoughts ...
What do you mean by this? Do you mean that that an implementation
cannot execute arbitrarily many iterations/recursions of that last
loop/definition in constant space?
And also said ...
If that's what you mean, you are wrong. GHC does that.
The IO monad would be pretty damned useless for actual
work if implementations did not do that!
So, my problem is that I find that my program crashes with
garbage collector can't collect enough memory after about
64 Million output operations.
What's really annoying is that I can write the whole thing
*recursively* in C in a very functional manner, and it works just
fine.
As I see it the problem is that and = are functions
and David is right about the not the last call problem.
But, Richard is right that related optimisations should
be possible in Haskell, and if not then you can kiss the
whole load good by and go back to system programming in C.
In particular I would claim that the definition:
recurse = f x = recurse
is essentially using = as a proxy temporal execution handler. So in
the above definition the call to recurse
*is* a last-call, at least according to =. I'm
probably saying that in a rather unorthodox manner,
but I hope my basic intention is clear.
In fact we can see in Haskell as rather kin to ; in C
(Or perhaps it should be =, since ; does transfer the
state to the subsequent computation).
So, I've loaded GHC and I'm looking to use it instead
(I expected to eventually anyway), but does this solve
my problem? Or have I misunderstood something here?
Also ... I've been using the graphics libs with HUGS,
but I can't find the equivalent in GHC ... what is
the recomended library for writing GUIs in GHC Haskell?
And where do I get it?
Thanks in advance ...
Bruce (IIMS, Massey at Albany).
ps: I've also been looking at Fudgets, but the code seems
a bit cranky.
___
Haskell mailing list
[EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Constant space infinite itteration ... solution?
[EMAIL PROTECTED] wrote: Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? My current favourite way to make GUI's is to use the GUI painter Glade and have it generate C code with calls to the Gtk GUI library, after that the only thing you have to implement are the callbacks. One big advantage Gtk offers over other GUI libraries is that it clearly separates the GUI construction code from the callback code, this makes it very suitable for GUI painters, i.e. the code the GUI painter generates doesn't have to be changed manually. Another advantage of Gtk, from the Haskell viewpoint, is that it was designed to work with other languages. Quoted from the Gtk page: GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. Although I haven't looked at the Haskell side in a while, everything to go from Glade to a Haskell GUI should all be there: http://www.gtk.org/ http://glade.gnome.org/ http://www.cse.unsw.edu.au/~chak/haskell/gtk/ The most recent version of Gtk+HS has support for libglade, this means you can directly read the Glade XML file that describes the GUI construction and the names of the callback functions. To be honest I don't know how the callbacks are actually connected to Haskell code, but there is probably an example in the Gtk+HS distribution to show how it works. Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Constant space infinite itteration ... solution?
On Friday, December 13, 2002, at 05:06 PM, Jan Kort wrote: Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? shameless advert You may as well try Gtk2HS which is a binding to Haskell specifically for Gtk version 2. http://gtk2hs.sourceforge.net /shameless advert Or look on the Haskell home page under libraries. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Error Handling
On 10-Dec-2002, Alastair Reid [EMAIL PROTECTED] wrote: On Sun, 8 Dec 2002, John Meacham wrote: (snip) throw (userException foo) + throw (userException bar) without defining an evaluation order you cannot know which exepction is to be thrown. catching the exception in the IO monad makes this 'okay' (snip) Mark Carroll [EMAIL PROTECTED] writes: Would it help if you defined an order over the possible exceptions, then if one is thrown you evaluate other parts of the expression to see if they also threw one, and return the first according to the ordering? I still haven't given up my hope for simple exceptions without monads. (-: To do this, we have to actually build the set of all exceptions that an expression could raise. This could take quite a while to build (lots more evaluation may need to be done) [playing devil's advocate for a moment] The set of all exceptions only needs to be built if an exception is actually raised. If no exception is raised, couldn't the code run just as fast as it currently does in Haskell? (My answer: yes, in theory it could; but only at the cost of major code bloat in the generated code and major increases in the degree of complication of the compiler. It's not worth the trade-off.) and getting any one exception probably isn't going to be any more useful than the 'random' choice you get at present. The advantage of what Mark Carroll was suggesting is not that you would get a more useful exception, just that you get a more predictable one, and that you don't need to use Monads. (My response: the potential advantages of more deterministic behaviour and [slightly] reduced need to use Monads would be outweighed by the drawbacks mentioned above, i.e. code bloat and compiler complexity.) And even this wouldn't get rid of the monads since the problem monads deal with is present even if we can't observe the exceptions. For example, a simple operation like this: choose :: a - a - a which returns its first argument if it can evaluate its argument to WHNF without raising an exception and returns its 2nd argument otherwise has severe semantic problems. That depends on what kind of exceptions you are trying to catch, doesn't it? If you need to catch out-of-memory errors (e.g. stack overflow or heap overflow), yes, that would cause semantic problems. Likewise for asynchronous exceptions/signals such as time-outs or user interrupts. But if `choose' is only catching exceptions raised by explicit calls to throw or error, then I think it would be semantically OK, wouldn't it? (Still, most of the time you probably do want to handle those kinds of errors -- at least the out-of-memory case, anyway -- so most of the time you'd still need Monads.) -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Monads [beginner]
Hi Joel and Jim - thanks for your useful responses to Marcos' question. I've added them to the UsingMonads page of the Haskell Wiki, http://www.haskell.org/wiki/wiki?UsingMonads Hope that's OK. Feel free to edit or extend or add your names if you like. To everyone else on the list: please add your nuggets of wisdom to the Wiki whenever you write a detailed answer to the email list. This way we can build up a repository of answers to FAQs very easily. Thanks! --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Error Handling
On Fri, 13 Dec 2002, Fergus Henderson wrote: (snip) and [slightly] reduced need to use Monads would be outweighed by the drawbacks mentioned above, i.e. code bloat and compiler complexity.) Ah - that's the impression I got from your earlier reply, too. (snip) time-outs or user interrupts. But if `choose' is only catching exceptions raised by explicit calls to throw or error, then I think it would be semantically OK, wouldn't it? (snip) That would actually be fine - I hadn't been hoping to catch errors that were things like user interrupts, which sound like they should be monadic anyway - just things explicitly thrown as you suggest. Admittedly, that is a rather important point that I should have made - I hadn't actually thought about errors caused by other stuff going on in the system and I completely agree that they should be wrapped in monads. Basically I was just wanting to replace some of the nastiness I have in code that passes two-tuples of (result, errors) around and has conditional statements to deal with backing up the functional call chain to deal with error conditions. What the code is doing can safely be done completely without monads so I didn't want any monads to be in the top-level type signature: all the errors involved are all things that were noticed in normal computation by matching otherwise in a guard and whatever, not IO or anything. -- Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
