March 2005 - Glasgow-haskell-users

RE: x86_64 port
by Simon Marlow 07 Mar '05

07 Mar '05

On 04 March 2005 22:54, Donald Bruce Stewart wrote: > simonmar: >> On 04 March 2005 16:59, John Goerzen wrote: >> >>> On Fri, Mar 04, 2005 at 04:57:04PM -0000, Simon Marlow wrote: >>>> On 04 March 2005 14:04, John Goerzen wrote: >>>>>> My amd64 hardware arrived yesterday, shouldn't be too long before >>>>>> we have a registerised port of GHC, and possibly a native code >>>>>> generator... >>>>> >>>>> <burns> excellent </burns> >>>> >>>> Don't hold your breath, I have some bad news. It seems that gcc is >>>> still generating incorrect code for register variables (or maybe >>>> it's broken again?). >>> >>> Which version of gcc? >> >> gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) > > I note that the GCC 4.0 branch is now being stabilised -- maybe that's > something to check. They claim it works with 4.0.0. Here's the bug I submitted: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359 Cheers, Simon

1 0

[ ghc-Feature Requests-1157515 ] GHCi support on x86_64
by SourceForge.net 07 Mar '05

07 Mar '05

Feature Requests item #1157515, was opened at 2005-03-06 00:25 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_… >Category: None >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: GHCi support on x86_64 Initial Comment: I just installed the 64bit version of ghc on an athlon 64. ghc does work and produces correct 64bit code, but ghci fails to start. Here is the complete output: [phil@athlon64 ~]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... /usr/lib64/ghc-6.2.2/HSbase.o: unknown architecture ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): loadObj: failed Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, or http://sourceforge.net/projects/ghc/. I'm using Fedora Core 3 and installed ghc using yum. If you have any questions, contact me: philipp.classen[AT]gmx.net Thanks, Philipp ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-03-07 12:03 Message: Logged In: YES user_id=48280 Changed to a feature request; GHCi support is simply not present on x86_64 yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1157515&group_…

1 0

RE: GHC 6.4 release candidates available
by Simon Marlow 07 Mar '05

07 Mar '05

On 04 March 2005 20:49, Keean Schupke wrote: > Further to my last point, what if the top level module is Main... > > ghci Main.hs > > and that includes a main function, and pragmas, so that main runs > when ghci is finished loading (automatically). GHCi doesn't run anything automatically. Could you elaborate? Cheers, Simon

2 1

RE: x86_64 port
by Simon Marlow 07 Mar '05

07 Mar '05

On 04 March 2005 17:48, Wolfgang Thaller wrote: > On 4-Mar-05, at 11:57 AM, Simon Marlow wrote: > >> Don't hold your breath, I have some bad news. It seems that gcc is >> still generating incorrect code for register variables (or maybe it's >> broken again?). > > So maybe this will be the first NCG-only port of GHC :-). > > Death to the Mangler! Yes, the same thought occurred to me... Simon

1 0

RE: GHC 6.4 release candidates available
by Simon Peyton-Jones 07 Mar '05

07 Mar '05

| >If you could specify overlapping on a per-instance basis, then that | >would be a way around the problem. Yes, that's the solution I prefer. The only question is when to action it.... | This worked in all GHCi before 6.4 - so something has broken the (in mu | opinion) correct | behavior. Was this a deliberate decision - or has something just changed | without anyone realising? I explained in an earlier message in this thread why the new behaviour was an accidental consequence of lazy reporting of overlapping instances. Simon

2 1

haddock: lexical error in string/character literal
by Gérard Milmeister 06 Mar '05

06 Mar '05

Hi, I stumbled on the dreaded "lexical error in string/character literal" while compiling haddock. Googling for this error, it seems that it is a problem with ghc-6.2.2 and gcc-3.4.2, the versions that I use. Is there a workaround for this? -- Gérard Milmeister Langackerstrasse 49 CH-8057 Zürich

1 0

6.4 snapshot installer available
by Sigbjorn Finne 04 Mar '05

04 Mar '05

http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) the only known omission from the bits intended to be included in the release proper is the PDF version of the user's guide. --sigbjorn

2 2

RE: x86_64 port
by Simon Marlow 04 Mar '05

04 Mar '05

On 04 March 2005 16:59, John Goerzen wrote: > On Fri, Mar 04, 2005 at 04:57:04PM -0000, Simon Marlow wrote: >> On 04 March 2005 14:04, John Goerzen wrote: >>>> My amd64 hardware arrived yesterday, shouldn't be too long before >>>> we have a registerised port of GHC, and possibly a native code >>>> generator... >>> >>> <burns> excellent </burns> >> >> Don't hold your breath, I have some bad news. It seems that gcc is >> still generating incorrect code for register variables (or maybe it's >> broken again?). > > Which version of gcc? gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

2 1

RE: GHC 6.4 release candidates available
by Simon Marlow 04 Mar '05

04 Mar '05

On 04 March 2005 12:58, Keean Schupke wrote: > There can only be one top level module in ghci (there can only > be one module name before the '>' prompt - that modules options > should be in effect. No, you can have multiple top-level module scopes in effect. See the GHCi documentation. > Simon Marlow wrote: > >> I think GHC's behaviour is right here. To use the flag settings from >> the source module on the command-line would be wrong: for example, >> when the module is compiled, its implementation (and therefore flag >> settings) must be hidden. >> >> > Requiring options on the command line exposes the implementation > I do not expect the GHCi user to be required to know which flags to > apply to get my code to run. Why not? You're providing a library which exports some instances. If overlapping instance resolution is required to resolve overloading in code that uses the library, I want to know about it, and I don't want the compiler to turn on overlapping instance resolution behind my back. Importing a library should *not* affect how the code that imports it is compiled, except in the ways you expect (bringing names and instances into scope). If you could specify overlapping on a per-instance basis, then that would be a way around the problem. Cheers, Simon

2 2

RE: x86_64 port
by Simon Marlow 04 Mar '05

04 Mar '05

On 04 March 2005 14:04, John Goerzen wrote: > On Fri, Mar 04, 2005 at 09:38:47AM -0000, Simon Marlow wrote: >>> Even if you're not running Debian, there are tools available to >>> convert a .deb to a RPM or tgz package. Or, you can easily unpack a >>> deb using only ar(1) and tar(1). >> >> My amd64 hardware arrived yesterday, shouldn't be too long before we >> have a registerised port of GHC, and possibly a native code >> generator... > > <burns> excellent </burns> Don't hold your breath, I have some bad news. It seems that gcc is still generating incorrect code for register variables (or maybe it's broken again?). I don't know if I can work around it yet. We'll see. Cheers, Simon

3 2