unsafeCorece is intended to be a no-op at run-time; that is, it has no work to do. Converting a pointer to one type of thing to a pointer to another type of thing is an example. Converting a 32-bit Int to a 64 bit int is *not* an example. Converting a 32-bit float to a 32-bit int (which you are trying here) may or may not be an example, I guess, depending on the architecture.
Rather than trying to keep casts, I'd suggest adding a new primop for non-trivial primitive-type conversions. There might be a lot of these I suppose; we could consider making them 'polymorphic', but retaining the type in STG land. Simon | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Simon Marlow | Sent: 11 March 2005 10:20 | To: Donald Bruce Stewart; glasgow-haskell-bugs@haskell.org | Subject: RE: Illtyped generated code with unsafeCoerce#, F# and -O | | On 11 March 2005 01:45, Donald Bruce Stewart wrote: | | > 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 | > 7777.0 | > (69,243,8,0) | > 7777.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: | > 7777.0 :: F32 & 255 | | I *think* the answer is that this kind of type casting just isn't | supported by the code generator at the moment. The Core is fine because | it includes the explicit type coercion, but this has been lost in the | STG code, and the code generator assumes that it is generating code for | type-correct STG code (although some coercions are allowed, ie. | coercions between values with the same MachRep). | | I can see at least two ways we might try to fix this: | | - try to detect type incompabilities in the STG->cmm code generator | and insert type casting operations. | | - possibly retain the type coercion from Core as an application of | a type-casting operation in STG, so the backend can generate | appropriate code for it. | | The latter sounds more promising. | | Cheers, | Simon | _______________________________________________ | 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
