Re: GHC 7.2.2 RC 1
On 11/6/2011 5:18 PM, Ian Lynagh wrote: 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be worked around. Please let us know if you find any showstoppers. #5531 is still there and no workarounds are known. Also, it's specific for post 7.0.Xs. Not sure if this counts as showstopper, though. Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Certainly doable but it does present a conundrum: for the old GHC (without builtin cl-support) the order for compilation seems to be: files> while for cl running link.exe or link.exe, it is better to put all the files at the end of the command line: It also adds one more layer of indirection a that delicate stage. Maybe some gcc mimicing cl wrapper tailored specifically for GHC building system could help? One more layer of indirection, but could leave ghc driver relatively intact. Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HDirect and GHC-6.6
Krasimir Angelov wrote: Some time ago I even started to design my own comlib. It is quite different from HDirect's comlib but is more closer in spirit to Haskell's FFI lib. It isn't completed yet but if someone is interested in I would upload it in darcs next week. It is living in Foreign.COM namespace. I'm very interested in such a library. I've also developed my own com (client) library, but as for now it is too raw to be published. Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC driver behaviour switch
Simon Marlow wrote: To fix this properly we should have a C++ compiler phase in DriverPipeline, it wouldn't be too hard. Care to submit a bug report with this info? Submitted. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC driver behaviour switch
Duncan Coutts wrote: On Thu, 2006-06-22 at 17:54 +0300, kyra wrote: With GHC 6.4.x I was able to use a ghc driver to compile .cpp sources. Now, with GHC HEAD I cannot. GHC HEAD now ALWAYS enforces "treat as .c" option. Just wondering, you're using ghc to compile C++ sources? Is there any reason for doing that rather than using the C++ compiler directly? Duncan The first and foremost reason - Cabal build infrastructure. I just put all my C++ sources in a "c-sources" section of my project. That's all. Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC driver behaviour switch
With GHC 6.4.x I was able to use a ghc driver to compile .cpp sources. Now, with GHC HEAD I cannot. GHC HEAD now ALWAYS enforces "treat as .c" option. Let's compare "DriverPipeline.hs". GHC 6.4.x: let langopt | hcc = [ SysTools.Option "-x", SysTools.Option "c"] | otherwise = [ ] SysTools.runCc dflags ( -- force the C compiler to interpret this file as C when -- compiling .hc files, by adding the -x c option. -- Also useful for plain .c files, just in case GHC saw a -- -x c option. langopt ++ ... GHC HEAD: SysTools.runCc dflags ( -- force the C compiler to interpret this file as C when -- compiling .hc files, by adding the -x c option. -- Also useful for plain .c files, just in case GHC saw a -- -x c option. [ SysTools.Option "-x", SysTools.Option "c"] ++ ... This completely breaks my build infrastructure. Could it be reversed? Cheers, Kyra ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inside the GHC code generator
Bulat Ziganshin wrote: i prefer to see the asm code. this may be because of better high-level optimization strategies (reusing fib values). the scheme about i say will combine advantages of both worlds no strategies, plain exponential algorithm, ocaml: _camlFibo__fib_57: subesp, 8 L101: cmpeax, 5 jgeL100 moveax, 3 addesp, 8 ret L100: movDWORD PTR 0[esp], eax addeax, -4 call_camlFibo__fib_57 L102: movDWORD PTR 4[esp], eax moveax, DWORD PTR 0[esp] addeax, -2 call_camlFibo__fib_57 L103: movebx, DWORD PTR 4[esp] addeax, ebx deceax addesp, 8 ret visual C++ 7.1 (next fastest): _fibPROC NEAR pushesi movesi, DWORD PTR 8[esp] cmpesi, 2 jgeSHORT $L945 moveax, 1 popesi ret0 $L945: leaeax, DWORD PTR [esi-2] pushedi pusheax call_fib decesi pushesi movedi, eax call_fib addesp, 8 addeax, edi popedi popesi ret0 _fibENDP also, Clean is *EXACTLY* in line with ocaml. This is interesting, because Clean is so much similar to Haskell. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: inside the GHC code generator
Bulat Ziganshin wrote: i think that ocaml can't generate code better than gcc and especially icc (intel C/C++ compiler), but may be i'm wrong? ;) didn't try factorial, but exponential fib in ocaml is *FASTER* than both gcc and intel c/c++ with highest optimization levels ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 6.3 windows (mingw) cannot invoke gcc correctly
Hi, After downgrading a mingw gcc from 3.3.1 to 3.2.3 I've managed to build and install ghc 6.3 compiler. Unfortunately, it cannot compile source files. It seems it incorrectly invokes gcc . "ghc -c -v filt.hs" gives something like this: ghc-6.3 (incorrect): ... *** Assembler g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.o Failed: g:\Progs\ghc-6.3\gcc -B"g:\Progs\ghc-6.3\gcc-lib/" -I. -I. -c C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc1252.s -o .\Main.orawSystem: does not exist (No such file or directory) ... ghc-6.0.1 (correct): ... *** Assembler G:\Progs\ghc-6.0.1\gcc -B"G:\Progs\ghc-6.0.1\gcc-lib/" "-I." "-I." "-c" "C:\DOCUME~1\Awson\LOCALS~1\Temp\ghc812.s" "-o" "filt.o" ... Meanwhile, ghc-6.3 correctly outputs intermediate .c or .s (when compiling without gcc) files. I'm completely stuck. Regards, Kyra ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Building ghc with mingw ghc 6.0.1 and gcc 3.3.1 problem
Hi, folks! Trying to build either 6.2 or 6.3 ghc with mingw ghc 6.0.1 and gcc 3.3.1, I get multiple "undefined reference to `__module_registered' " errors during a stage2 ghc linking. Is the gcc 3.3 behaviour the case? Regards, Kyra ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
