Illtyped generated code with unsafeCoerce#, F# and -O

[Simon Peyton-Jones]

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: glasgow-haskell-bugs-bounces at haskell.org
[mailto:glasgow-haskell-bugs-
| bounces at haskell.org] On Behalf Of Simon Marlow
| Sent: 11 March 2005 10:20
| To: Donald Bruce Stewart; glasgow-haskell-bugs at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs