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
