Illtyped generated code with unsafeCoerce#, F# and -O
simonmar at microsoft.com
Fri Mar 11 07:50:06 EST 2005
Agree, a primop would be a more robust solution.
I think it's more correct to say that unsafeCoerce can only coerce from
type T to U iff typeCgReg T == typeCgRep U (hmm, this is necessary, but
not sufficient). We might want to check for this?
Don: as a quick hack, you could use an inline C function to do the cast.
I think we ought to support inline C-- these days - after all, we have a
C-- parser in the compiler!
On 11 March 2005 11:02, Simon Peyton-Jones wrote:
> 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.
>> -----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
>>> When working it runs and produces the following (correct) result:
>>> paprika$ ./a.out
>>> 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
>> 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.
>> Glasgow-haskell-bugs mailing list
>> Glasgow-haskell-bugs at haskell.org
More information about the Glasgow-haskell-bugs