- ghc-devs - Haskell.org

RE: We need to add role annotations for 7.8
by Simon Peyton Jones 25 Mar '14

25 Mar '14

When Brandon says “potential bugs/unsafety and all” he means GeneralisedNewtypeDeriving (GND). That already exists, and already allows you to do bad things (Trac #1496 among others). See the thread on https://ghc.haskell.org/trac/ghc/ticket/8827, starting especially at comment 17 for more discussion and some insightful comments. As Edward (on the ticket) and Brandon (here) point out, going to “nominal by default” will be very safe but it’ll break many Haskell packages which use GND. This is really a library/user question, not a GHC one. We can implement whatever default you want. But GHC 7.8 is about to be released and this debate has been going on for some weeks, at high intensity on ghc-devs, plus Richard specifically advertised it to the libraries list back in November<http://www.haskell.org/pipermail/libraries/2013-November/021707.html>, and again a couple of weeks ago<http://www.haskell.org/pipermail/libraries/2014-March/022321.html>. I think the status quo is not unreasonable. One question you might want to debate is whether, as Brandon suggests, you want to move to “nominal by default” in due course. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Brandon Allbery Sent: 24 March 2014 14:28 To: Mark Lentczner Cc: GHC Development Mailing List; libraries(a)haskell.org Libraries Subject: Re: We need to add role annotations for 7.8 On Mon, Mar 24, 2014 at 10:14 AM, Mark Lentczner <mark.lentczner(a)gmail.com<mailto:mark.lentczner@gmail.com>> wrote: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell(a)gmail.com<mailto:johan.tibell@gmail.com>> wrote: I'm quite worried about this change though. I thought the default role for data type was nominal, as that's the safe default. If the default is representational, every package author will need to be aware of this feature and update their packages. That's quite a high cost. On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b(a)gmail.com<mailto:allbery.b@gmail.com>> wrote: Nominal default breaks everything that uses newtype deriving and doesn't have role annotations, doesn't it? Representational default means things behave in 7.8 as they did in earlier GHCs. Am I reading these pair of statements correctly? It seems to imply to me that every parameterized type that uses a type constraint on a parameter must be reviewed and possibly annotated to work correctly, one way or the other! No; if the default is representational, everything works as it did in earlier versions, potential bugs/unsafety and all. If the default is immediately switched to nominal, *then* every affected type must be reviewed immediately. My counter-proposal was to have 7.8 default to representational to give library maintainers a release cycle to add the necessary annotations, then switch the default to nominal in 7.10 to get the additional safety. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

5 7

module ‘free-4.6.1:Main’ is defined in multiple files
by Mateusz Kowalczyk 24 Mar '14

24 Mar '14

Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon™ (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone git@github.com:ekmett/free.git && cd free 4. cabal install --only-dependencies --enable-documentation && cabal configure && cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K.

2 1

Merge CmpNat and CmpSymbol in 7.8
by Iavor Diatchki 24 Mar '14

24 Mar '14

Hi, based on requests from a couple of people I added a couple of type-level functions for type nats and type symbols. Could we get these merged in 7.8? The relevant commits are: In GHC: 5e4bdb5fc5e741522cbb787731422da3f12aa398 Implement ordering comparisons for type-level naturals and symbols. In base: 5edb063688e73ec00fd1f61ac0e8317dd122f44a Comments only. c1d3546420ee482bbbd9f15d45a6e8a26304d419 Add functions for comparing type-level Nats and Symbols. Thanks! -Iavor

1 0

Re: We need to add role annotations for 7.8
by Mark Lentczner 24 Mar '14

24 Mar '14

On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery <allbery.b(a)gmail.com>wrote: > No; if the default is representational, everything works as it did in > earlier versions, potential bugs/unsafety and all. If the default is > immediately switched to nominal, *then* every affected type must be > reviewed immediately. > Now I'm confused about the current state of the default.... But it doesn't matter either way: The Platform is expected to work cohesively with the GHC release, and either of these defaults spells a huge amount of work for the Platform. > My counter-proposal was to have 7.8 default to representational to give > library maintainers a release cycle to add the necessary annotations, then > switch the default to nominal in 7.10 to get the additional safety. > This is unworkable. How much conditional code do you want library writers to have to have? Library writers strive to have code which works with n prior releases where n is commonly 3. Having code that works with 7.6, 7.8, and 7.10 would be a nighmare! On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > perhaps there should be some mechanism to specify to ghc 7.8 whether a > compile should default to representational or nominal so that authors have > a way to test their code / look for problems. > Also unworkable... now we need a conditional flag for the state of the default so the code can be written to work with either based on a GHC flag? And how is that supposed to work with already compiled dependencies (sandboxed or not)? Is cabal now to take this flag into account? the Package manager signatures too? The major problem with this feature is that it is massively global in scope. This is extremely rare for GHC extensions (Safe comes to mind)... and with good reason: It is very very expensive. The motivating case here, a compiler checked safe zero-cost coerce, seems way out of proportion to the cost: Careful review of every library abstract type, and addition of *three+* lines of source (remember, this must be CPP guarded, so you have to add CPP extension on to every file, too).

2 1

Re: We need to add role annotations for 7.8
by Mark Lentczner 24 Mar '14

24 Mar '14

Speaking from the vantage point of platform.... This pair of comments (emphasis mine) have my alarm index on high: On Fri, Mar 14, 2014 at 2:36 AM, Johan Tibell <johan.tibell(a)gmail.com>wrote: > I'm quite worried about this change though. I thought the default rolefor data type was nominal, as that's the safe default. *If > the default is representational, every package author will need to be aware > of this feature and update their packages.* That's quite a high cost. > On Fri, Mar 14, 2014 at 6:00 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > *Nominal default breaks everything that uses newtype deriving and doesn't > have role annotations, doesn't it?* Representational default means things > behave in 7.8 as they did in earlier GHCs. > Am I reading these pair of statements correctly? It seems to imply to me that *every* parameterized type that uses a type constraint on a parameter *must* be reviewed and possibly annotated to work correctly, one way or the other! Seems so: On Fri, Mar 14, 2014 at 7:22 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > So, the best thing we came up with is this: Libraries that wish to export > abstract data types must do two things: > 1. Manage export lists carefully. > *2. Use role annotations.* > This is huge order, and one that will produce significant strain on the ecosystem. For one, this will set back Haskell Platform months: We have 250k lines of Haskell by 30+ authors that will need to be reviewed and updated. And all of this is so that data types can be coerced more safely? While I'm all for safely, the number of places where coercion is that important seems very small... and this addition to the language and burden on the libraries very high. If this feature cannot be added safely without reviewing 1/4 million lines of library code (not to mention all of hackage)... Then I think it isn't ready and shouldn't be released in 7.8. - Mark

2 1

Re: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a POSIX way (fixes #8781) (e7563ec)
by Jost Berthold 24 Mar '14

24 Mar '14

Hello, With the patch to deriveConstants, a build on an older Windows (32bit Vista, MinGW32 installation, which used to work) now fails with error Can't find "STD_HDR_SIZE" I ran the nm command manually on the generated o file (includes/dist-derivedconstants/header/tmp.o) and saw that the output follows pattern _derivedConstantBlaBlah_Blah C 000001b so it does not match the four-word pattern in the patch. Is this a problem with my setup, or does it fail for other people on Windows as well? Thanks, Jost On 03/23/2014 08:46 AM, ghc-commits-request(a)haskell.org wrote: > Message: 6 > Date: Sun, 23 Mar 2014 02:01:50 +0000 (UTC) > From: git(a)git.haskell.org > To: ghc-commits(a)haskell.org > Subject: [commit: ghc] ghc-7.8: change deriveConstants to use nm in a > POSIX way (fixes #8781) (e7563ec) > Message-ID: <20140323020150.1DCE82406B(a)ghc.haskell.org> > Content-Type: text/plain; charset=utf-8 > > Repository : ssh://git@git.haskell.org/ghc > > On branch : ghc-7.8 > Link : http://ghc.haskell.org/trac/ghc/changeset/e7563ec2e03740074903036bf129fc972… > >> --------------------------------------------------------------- > > commit e7563ec2e03740074903036bf129fc972b623c23 > Author: Karel Gardas <karel.gardas(a)centrum.cz> > Date: Sat Mar 22 22:33:05 2014 +0100 > > change deriveConstants to use nm in a POSIX way (fixes #8781) > > The patch provided by Christian Maeder <Christian.Maeder(a)dfki.de> > > Signed-off-by: Karel Gardas <karel.gardas(a)centrum.cz> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > (cherry picked from commit 045b28033a33a48d31951240a8cb35f2b78345dc) > > >> --------------------------------------------------------------- > > e7563ec2e03740074903036bf129fc972b623c23 > utils/deriveConstants/DeriveConstants.hs | 30 ++++++++++-------------------- > 1 file changed, 10 insertions(+), 20 deletions(-) > > diff --git a/utils/deriveConstants/DeriveConstants.hs b/utils/deriveConstants/DeriveConstants.hs > index 10df61c..54ee6a1 100644 > --- a/utils/deriveConstants/DeriveConstants.hs > +++ b/utils/deriveConstants/DeriveConstants.hs > @@ -638,7 +638,7 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram > oFile = tmpdir </> "tmp.o" > writeFile cFile cStuff > execute verbose gccProgram (gccFlags ++ ["-c", cFile, "-o", oFile]) > - xs <- readProcess nmProgram [oFile] "" > + xs <- readProcess nmProgram ["-P", oFile] "" > let ls = lines xs > ms = map parseNmLine ls > m = Map.fromList $ catMaybes ms > @@ -707,27 +707,17 @@ getWanted verbose tmpdir gccProgram gccFlags nmProgram > doWanted (ClosurePayloadMacro {}) = [] > doWanted (FieldTypeGcptrMacro {}) = [] > > - -- parseNmLine parses nm output that looks like > - -- "0000000b C derivedConstantMAX_Vanilla_REG" > + -- parseNmLine parses "nm -P" output that looks like > + -- "_derivedConstantMAX_Vanilla_REG C b 0" Mac OS X > + -- "derivedConstantMAX_Vanilla_REG C 0000000b 0000000b" GNU > + -- "derivedConstantMAX_Vanilla_REG D 1 b" Solaris > -- and returns ("MAX_Vanilla_REG", 11) > - parseNmLine xs0 = case break (' ' ==) xs0 of > - (x1, ' ' : xs1) -> > - case break (' ' ==) xs1 of > - (x2, ' ' : x3) -> > - case readHex x1 of > - [(size, "")] -> > - case x2 of > - "C" -> > - let x3' = case x3 of > - '_' : rest -> rest > - _ -> x3 > - in case stripPrefix prefix x3' of > - Just name -> > - Just (name, size) > - _ -> Nothing > - _ -> Nothing > - _ -> Nothing > + parseNmLine xs0 = case words xs0 of > + [x0, x1, x2, x3] -> case stripPrefix prefix $ dropWhile (== '_') x0 of > + Just name -> case readHex $ if x1 == "C" then x2 else x3 of > + [(size, "")] -> Just (name, size) > _ -> Nothing > + _ -> Nothing > _ -> Nothing > > -- If an Int value is larger than 2^28 or smaller

5 10

FW: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0)
by Simon Peyton Jones 24 Mar '14

24 Mar '14

Austin, this one looks like a bug waiting to happen, so let's merge if time. Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 24 March 2014 10:27 To: ghc-commits(a)haskell.org Subject: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0) Repository : ssh://git@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/74894e0bc405247092e865b9541f5f18d… >--------------------------------------------------------------- commit 74894e0bc405247092e865b9541f5f18d26aa015 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Mar 21 15:24:49 2014 +0000 Add missing kind-check for tcEqType on forall-types This wasn't showing up as a bug, but it was definitely wrong. >--------------------------------------------------------------- 74894e0bc405247092e865b9541f5f18d26aa015 compiler/typecheck/TcType.lhs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index 9b58b4c..08c7a62 100644 --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -245,7 +245,6 @@ checking. It's attached to mutable type variables only. It's knot-tied back to Var.lhs. There is no reason in principle why Var.lhs shouldn't actually have the definition, but it "belongs" here. - Note [Signature skolems] ~~~~~~~~~~~~~~~~~~~~~~~~ Consider this @@ -1008,7 +1007,8 @@ tcEqType ty1 ty2 | Just t2' <- tcView t2 = go env t1 t2' go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1) (LitTy lit2) = lit1 == lit2 - go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 + go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + && go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 && go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 && go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2 @@ -1027,7 +1027,8 @@ pickyEqType ty1 ty2 init_env = mkRnEnv2 (mkInScopeSet (tyVarsOfType ty1 `unionVarSet` tyVarsOfType ty2)) go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1) (LitTy lit2) = lit1 == lit2 - go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 + go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + && go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 && go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 && go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2 _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

7.8.1 RC testsuite failures for 64bit unregisterised builds
by Jens Petersen 24 Mar '14

24 Mar '14

(changing Subject to "fork" this to a separate thread) On 23 March 2014 21:42, Peter Trommler <ptrommler(a)me.com> wrote: > On 23.03.2014, at 11:44, Jens Petersen <petersen(a)fedoraproject.org> wrote: > >> Speaking of ppc64: Do you see ticket #8849 too? > > Does it show up in the testsuite results too? > > Yes, in fact I noticed the error in test arith005 and extracted the small > test case > for #8849. > Okay I did a ppc64 build with the testsuite: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1731757 and reproduced #8849 and (probably) #8819 too. I say "probably" since my ppc64 testsuite results are littered with "Actual stderr output differs from expected:" warnings caused by: """ + +In file included from /usr/include/math.h:26:0: + 0, + from /builddir/build/BUILD/ghc-7.8.0.20140228/includes/Stg.h:65, + from /tmp/ghc25682_0/ghc25682_3.hc:3: + +/usr/include/features.h:148:3: + warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] + # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" + ^ """ I only see those on ppc64 so far. Perhaps there is some way to ignore those? In #8819 I reported test failures in an unregisterised compiler produced on > my x86_64 machine using an unregisterised ghc. Almost all arith tests > including arith005 > fail and I suspect it might be a data layout issue. I wonder if you can > reproduce > #8819 on ppc64. #8849 makes me think yes. I reproduced also on s390x: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1369051 including #8819 unfortunately !! So seems this happens on ppc64, s390x and x86_64 for unregisterised. I know "unregisterised" may be considered less supported these days but this seems quite serious and I hope it could still be fixed for 7.8.1. Jens

1 0

Re: [commit: ghc] ghc-7.8: add --with-ar and --with-ranlib configure parameters (05e160e)
by Gabor Greif 23 Mar '14

23 Mar '14

Committed as 61654e5 Cheers, Gabor On 3/23/14, Karel Gardas <karel.gardas(a)centrum.cz> wrote: > > Hi Gabor, > > indeed! I can just follow my intention to follow general logic of: > > --with-<cmd> -> @<cmd>Cmd@ > > but you are right RANLIB logic is a little bit more comlex in aclocal.m4 > so it uses different variables (REAL_RANLIB_CMD/RANLIB_CMD) than "usual" > RanlibCmd. > > So if you care about one useless AC_SUBST(RanlibCmd), please send the > patch or if you do have commit access just fix that. As I said, > intention was to follow usual logic although in this case > non-functional.... > > Thanks, > Karel > > On 03/23/14 09:35 PM, Gabor Greif wrote: >> Hi Karel, >> >> I am missing a use of @RanlibCmd@, is this intentional? >> >> Cheers, >> >> Gabor >> >> On 3/23/14, git(a)git.haskell.org<git(a)git.haskell.org> wrote: >>> Repository : ssh://git@git.haskell.org/ghc >>> >>> On branch : ghc-7.8 >>> Link : >>> http://ghc.haskell.org/trac/ghc/changeset/05e160e36527f6f36f997d7aa56f0cbe4… >>> >>>> --------------------------------------------------------------- >>> >>> commit 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3 >>> Author: Karel Gardas<karel.gardas(a)centrum.cz> >>> Date: Sun Feb 9 21:58:05 2014 +0100 >>> >>> add --with-ar and --with-ranlib configure parameters >>> >>> Both --with-ar and --with-ranlib are usable on non-GNU/Linux >>> systems >>> where GNU tools are usually installed (or possible to install), but >>> not into standard location nor with standard name. Tested on >>> Solaris >>> 10. >>> >>> Signed-off-by: Austin Seipp<austin(a)well-typed.com> >>> (cherry picked from commit >>> ac24bf45258af701cdd67423d6107357f27bbedf) >>> >>> >>>> --------------------------------------------------------------- >>> >>> 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3 >>> configure.ac | 15 +++++++++++++++ >>> mk/config.mk.in | 1 + >>> 2 files changed, 16 insertions(+) >>> >>> diff --git a/configure.ac b/configure.ac >>> index 1c58da0..d32fd20 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -486,6 +486,21 @@ FP_ARG_WITH_PATH_GNU_PROG([NM], [nm], [nm]) >>> NmCmd="$NM" >>> AC_SUBST([NmCmd]) >>> >>> +dnl ** Which ar to use? >>> +dnl -------------------------------------------------------------- >>> +FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar]) >>> +ArCmd="$AR" >>> +fp_prog_ar="$AR" >>> +AC_SUBST([ArCmd]) >>> + >>> +dnl ** Which ranlib to use? >>> +dnl -------------------------------------------------------------- >>> +FP_ARG_WITH_PATH_GNU_PROG([RANLIB], [ranlib], [ranlib]) >>> +RanlibCmd="$RANLIB" >>> +RANLIB="$RanlibCmd" >>> +AC_SUBST([RanlibCmd]) >>> + >>> + >>> # Note: we may not have objdump on OS X, and we only need it on >>> Windows >>> (for DLL checks) >>> case $HostOS_CPP in >>> cygwin32|mingw32) >>> diff --git a/mk/config.mk.in b/mk/config.mk.in >>> index fef1fb8..7cc7aec 100644 >>> --- a/mk/config.mk.in >>> +++ b/mk/config.mk.in >>> @@ -661,6 +661,7 @@ DTRACE = @DtraceCmd@ >>> >>> LD = @LdCmd@ >>> NM = @NmCmd@ >>> +AR = @ArCmd@ >>> OBJDUMP = @ObjdumpCmd@ >>> >>> LLC = @LlcCmd@ >>> >>> _______________________________________________ >>> ghc-commits mailing list >>> ghc-commits(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-commits >>> >> > >

1 0

When iselExpr64 (CmmLit (CmmInt i _)) is used?
by Karel Gardas 23 Mar '14

23 Mar '14

Hello, I'm trying to resurrect SPARC NCG. I've switched it on and basically provided functions on which NCG has panic during the build, basically just 2 were missing so far (cut from git diff): +genCCall (PrimTarget MO_Touch) _ _ + = return $ nilOL + +iselExpr64 (CmmLit (CmmInt i _)) = do + (rlo, rhi) <- getNewRegPairNat II32 + let + half0 = fromIntegral (fromIntegral i :: Word32) + half1 = fromIntegral (fromIntegral (i `shiftR` 32) :: Word32) + code = toOL [ + SETHI (HI $ ImmInt half0) rlo, + OR False rlo (RIImm (LO $ ImmInt half0)) rlo, + SETHI (HI $ ImmInt half1) rhi, + OR False rhi (RIImm (LO $ ImmInt half1)) rhi + ] + return (ChildCode64 code rlo) Now, my ghc-stage2 badly fails and testsuite run with stage=1 reveals 1390 unexpected failures. Perhaps this is unrelated, but still I'd like to test that my iselExpr64 implementation above is correct. Is there any simple haskell code which makes this function in NCG run? I'm trying this: import GHC.Prim import GHC.Exts main = do let x = 18446744073709551615# --- 2^64-1 = 18446744073709551615 putStrLn (show $ I# x) return() I've had a hope that unboxed long int constant is what causes iselExpr64 being called, but generated assembly looks suspicious -- like it's not called so my idea was wrong here probably. Do you have any idea how to test this function and see its generated assembly? BTW: I hope I got the function semantics correct as a loading of 64bit constant/integer into a pair of 32bits registers... Thanks a lot! Karel

2 2