Re: Illtyped generated code with unsafeCoerce#, F# and -O
wolfgang.thaller:
> >g (F# f) =
> >let w = W32# (unsafeCoerce# f)
>
> Why does GHC even accept this code?
> I think unsafeCoerce# is not intended to be able to coerce unboxed
> values.
>
> Prelude GHC.Base> :t unsafeCoerce#
> unsafeCoerce# :: forall b a. a -> b
>
> The type variables a and b are supposed to be of kind *, and f is of
> kind #.
How do you know the tyvars have kind * ? Anyway, it's even used like
this in the libraries :)
GHC.Conc:
mkWeak key val Nothing = IO $ \s ->
case mkWeak# key val (unsafeCoerce# 0#) s of
{ (# s1, w #) -> (# s1, Weak w #) }
So those tyvars must really be ? kind (I think). I.e.
forall b:? a:? . a -> b
or
forall b:?? a:?? . a -> b
There's a description of this stuff in types/Kind.lhs.
Also, I see in basicTypes/MkId.lhs:
unsafeCoerce# isn't so much a PrimOp as a phantom identifier, that
just gets expanded into a type coercion wherever it occurs. Hence we
add it as a built-in Id with an unfolding here.
The type variables we use here are "open" type variables: this means
they can unify with both unlifted and lifted types. Hence we provide
another gun with which to shoot yourself in the foot.
open == ??, I think, and the above comment explains the unsafeCoerce# behaviour
I'm using/shooting myself with. Further down:
ty = mkForAllTys [openAlphaTyVar,openBetaTyVar]
(mkFunTy openAlphaTy openBetaTy)
which looks like: a:?? -> b:?? to me. In prelude/TysPrim.lhs:
-- openAlphaTyVar is prepared to be instantiated
-- to a lifted or unlifted type variable. It's used for the
-- result type for "error", so that we can have (error Int# "Help")
openAlphaTy = mkTyVarTy openAlphaTyVar
So I think this all implies that unsafeCoerce# x# is legal, though not polite.
Cheers,
Don
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Illtyped generated code with unsafeCoerce#, F# and -O
g (F# f) = let w = W32# (unsafeCoerce# f) Why does GHC even accept this code? I think unsafeCoerce# is not intended to be able to coerce unboxed values. Prelude GHC.Base> :t unsafeCoerce# unsafeCoerce# :: forall b a. a -> b The type variables a and b are supposed to be of kind *, and f is of kind #. If we have any other function of type a -> b, for example foo :: a -> b foo _ = undefined Then GHCi rejects "foo 1.0#" and prints: :1:4: Couldn't match kind `*' against `#' When matching the kinds of `t :: *' and `Float# :: #' Expected type: t Inferred type: Float# In the first argument of `foo', namely `1.0#' Cheers, Wolfgang ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Illtyped generated code with unsafeCoerce#, F# and -O
Hey guys, The following (evil, yes) program compiles and works under ghc -Onot using -fasm or -fvia-C, but fails to generated correct code under all GHCs back to ghc-5.04.2 if I turn on -O. (It also works under ghci). When working it runs and produces the following (correct) result: paprika$ ./a.out .0 (69,243,8,0) .0 However, if I turn on -O it fails to generate acceptable asm or C. Am I right in thinking that all uses of unsafeCoerce# should never cause type-incorrect C or asm code to be generated (no matter what evil happens at runtime)? Now, -dcore-lint is fine, but our shiny new 6.4 -dcmm-lint spots the error :) Cmm lint error: in proc s2D4_ret in basic block c2F7 in MachOp application: .0 :: F32 & 255 Here's the result -O -fvia-C: paprika$ ghc-6.4 -no-recomp -fglasgow-exts -O -fvia-C t.hs /tmp/ghc5870.hc: In function `s2D4_ret': /tmp/ghc5870.hc:253: error: invalid operands to binary & /tmp/ghc5870.hc: In function `Main_lvl2_entry': /tmp/ghc5870.hc:412: error: invalid operands to binary & where relevant lines are: 253: _s2D8 = ((StgFloat).0) & 0xff; and 472: _s2Dg = ((StgFloat).0) & 0xff; There appears to be a missing (W_) cast (?). And -O -fasm: paprika$ ghc-6.4 -no-recomp -fglasgow-exts -O -fasm t.hs /tmp/ghc7685.s: Assembler messages: /tmp/ghc7685.s:309: Error: bad register name `%st(-7)' /tmp/ghc7685.s:316: Error: bad register name `%fake0' /tmp/ghc7685.s:317: Error: bad register name `%fake0' /tmp/ghc7685.s:472: Error: bad register name `%st(-7)' the relevant lines are: 309: ffree %st(7) ; flds .Ln2GX ; fstp %st(-7) 316: movl 8(%ebp),%fake0 317: orl %eax,%fake0 472: ffree %st(7) ; flds .Ln2HH ; fstp %st(-7) We get a similar result with ghc-6.2.2 (but of course don't have a -dcore-lint pass to spot the type error ;) paprika$ ghc-6.2.2 -no-recomp -keep-tmp-files -fglasgow-exts -O -fasm t.hs /tmp/ghc4107.s: Assembler messages: /tmp/ghc4107.s:278: Error: bad register name `%st(-7)' /tmp/ghc4107.s:675: Error: bad register name `%fake0' /tmp/ghc4107.s:676: Error: bad register name `%fake0' paprika$ ghc-6.2.2 -no-recomp -keep-tmp-files -fglasgow-exts -O -fvia-C t.hs /tmp/ghc7876.hc: In function `Main_zdwg_entry': /tmp/ghc7876.hc:221: error: invalid operands to binary & And even back to ghc-5.04.2: zywiec$ ghc-5.04.2 -O -fglasgow-exts -fvia-C t.hs /tmp/ghc2973.hc: In function `Main_a_entry': /tmp/ghc2973.hc:27: invalid operands to binary & zywiec$ ghc-5.04.2 -O -fglasgow-exts -fasm t.hs /tmp/ghc2977.s: Assembler messages: /tmp/ghc2977.s:79: Error: bad register name `%st(-7)' /tmp/ghc2977.s:774: Error: bad register name `%fake0' /tmp/ghc2977.s:775: Error: bad register name `%fake0' /tmp/ghc2977.s:776: Error: bad register name `%fake0' /tmp/ghc2977.s:777: Error: bad register name `%fake0' -- Don And here's the nefarious code: import GHC.Word import GHC.Float import GHC.Base import Data.Bits main = let f = .0 f' = g f f''= g' f' in do putStrLn (show f) putStrLn (show f') putStrLn (show f'') g :: Float -> (Word8,Word8,Word8,Word8) g (F# f) = let w = W32# (unsafeCoerce# f) w0= fromIntegral (w `shiftR` 24) w1= fromIntegral ((w `shiftR` 16) .&. 0xff) w2= fromIntegral ((w `shiftR` 8) .&. 0xff) w3= fromIntegral (w .&. 0xff) in (w0,w1,w2,w3) g' :: (Word8,Word8,Word8,Word8) -> Float g' (w0,w1,w2,w3) = let (W32# w) = (fromIntegral w0 `shiftL` 24) .|. (fromIntegral w1 `shiftL` 16) .|. (fromIntegral w2 `shiftL` 8) .|. (fromIntegral w3) in F# (unsafeCoerce# w) ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
"impossible happened" with "class XML a where toXML :: a -> XML"
Breaking code is:
"class XML a where toXML :: a -> XML"
result is:
Compiling Main ( /home/shae/src/haskell/ProtoWebPublish.hs, interpreted )
ghc-6.4.20050303: panic! (the `impossible' happened, GHC version 6.4.20050303):
ds_app_type Main.XML{tc r1BX} []
Not sure if this is already a known bug.
--
Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said:
You could switch out the unicycles for badgers, and the game would be the same.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: {-# SPECIALIZE, IO vs ST s
On Thu, Mar 10, 2005 at 02:18:59PM +0100, Remi Turk wrote: > first of all, I'm not sure whether this is actually a bug-report > or a feature-request. > > The three line summary is that in the following program, no > specialized version for ST s is created by at least 6.2.1, > 6.4.20050304, and 6.4.20050308. This is bug no. 1019758. See also http://www.haskell.org/pipermail/glasgow-haskell-users/2004-June/006874.html ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
{-# SPECIALIZE, IO vs ST s
Hello again,
first of all, I'm not sure whether this is actually a bug-report
or a feature-request.
The three line summary is that in the following program, no
specialized version for ST s is created by at least 6.2.1,
6.4.20050304, and 6.4.20050308.
{-# OPTIONS -fno-implicit-prelude #-}
module MHashTable () where
import GHC.Base ( RealWorld, Monad, return )
import GHC.IOBase ( IO )
import Control.Monad.ST ( ST )
{-# SPECIALIZE bucketIndex :: ST s () #-}
{-# SPECIALIZE bucketIndex :: IO () #-}
bucketIndex :: Monad m => m ()
bucketIndex = return ()
Practically any other specialization, including Maybe, [] and ST RealWorld
_are_ actually performed.
What GHC has to say about it:
% /var/tmp/ghc/bin/ghc -O --make -ddump-rules MHashTable.hs
Chasing modules from: MHashTable.hs
Compiling MHashTable ( MHashTable.hs, MHashTable.o )
Top-level specialisations
"SPEC MHashTable.bucketIndex" __forall {$dMonad :: {GHC.Base.Monad
GHC.IOBase.IO}}
MHashTable.bucketIndex @ GHC.IOBase.IO $dMonad
= $sbucketIndex ;
In case anyone is wondering "what's the point, it'll get inlined
anyway", I'm trying to enhance Data.HashTable to work both with
IO and ST s without duplicating the whole module or flushing
performance down the drain, and the real functions are quite a
bit bigger, hence won't be inlined.
Right now, I have four versions:
Data.HashTable, STHashTable (specialized for ST s), and
MHashTable which works with a typeclass for both IO and ST s.
The first two, and MHashTable instantiated on IO are about
equally fast, but as SPECIALIZE doesn't seem to have much effect
on ST s, MHashTable instantiated on ST s is about two times
slower.
Greetings,
Remi
--
Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: retainer profiling documentation
Thanks for a constructive suggestion. We've incorporated your rewording. I'll take this opportunity to encourage GHC users to offer suggested rewording or clarifications to GHC's documentation. We're far more likely to do something if you suggest an improvement in concrete terms, rather than simply say "this should be better documented" (which is almost invariably true!). And you're also in a much better position to write clear documentation from the point of view of a user, than we are as implementers. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 09 March 2005 20:43 | To: glasgow-haskell-bugs@haskell.org | Subject: retainer profiling documentation | | I think the documentation for retainer profiling could be clearer... | | > 5.4.2. Retainer Profiling | > | > Retainer profiling is designed to help answer questions like "why is | > this data being retained?". We start by defining what we mean by a | > retainer: | > | > A retainer is either the system stack, or an unevaluated closure (thunk). | > | > In particular, constructors are not retainers. | > | > An object A is retained by an object B if object A can be reached by | > recursively following pointers starting from object B but not meeting | > any other retainers on the way. Each object has one or more retainers, | > collectively called its retainer set. | | I'm not sure I understand this but I'll try to rephrase it in a way | which I think is easier to parse. | | > 5.4.2. Retainer Profiling | > | > Retainer profiling is designed to help answer questions like "why is | > this data being retained?". We start by defining what we mean by a | > retainer object: | > | > A retainer object is either the system stack, or an unevaluated | > closure (thunk). | > | > In particular, constructors are not retainer objects. | > | > Now we define what it means for one object to retain another: | > | > An object B retains object A if it is a retainer object and | > object A can be reached by recursively following pointers | > starting from object B, but not meeting any other retainer | > objects on the way. Each object is retained by one or more | > retainer objects, collectively called its retainer set, or its | > retainers. | | Is this OK? I'm trying to distinguish the class of objects which are | allowed to be retainers - thunks and the stack - from ones which | actually retain other objects. E.g. one could have a thunk which | doesn't retain anything, I think it's confusing to define such a thing | as a "retainer", I thought "retainer object" would be clearer. | | Frederik | | -- | http://ofb.net/~frederik/ | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: environment variables for ghc
OK, well I'll be busy for the next few weeks so if someone else wants to step up and do it, don't wait for me. But otherwise I'll put in on my todo list. Cheers, Frederik On Wed, Mar 09, 2005 at 10:40:03PM -, Simon Marlow wrote: > On 09 March 2005 21:13, Frederik Eaton wrote: > > >>> I agree that the case you're presenting is indeed more difficult, > >>> but I don't think you're doing the estimations right for the one at > >>> hand. The cost and annoyance of perhaps tens of thousands of people > >>> adding and remembering to maintain wrappers named 'ghc' somewhere > >>> in their path to accomplish this simple task (after scrounging in > >>> the documentation to find that ghc for some reason fails to be like > >>> many other compilers, a nontrivial cost in itself since the lack of > >>> environment variables isn't specifically documented) - or simply not > >>> doing so, and typing in -package-conf hundreds of times as I have > >>> done, because they may not have write access to the main > >>> package.conf - I think outweighs the cost of one person, once, > >>> adding central support for environment variables, a bit of > >>> documentation in the man page, perhaps a ghcbug program if we want > >>> super-detailed bug reports... > >> > >> Are you volunteering to be that person? ;-) > > > > Are you saying that a patch would be accepted? > > > > Frederik > > We'll definitely take the environment variable patch if it comes with a > ghcbug script :-) > > Cheers, > Simon > -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
