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!
Cheers,
Simon
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.
>
> 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; [email protected]
>> 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
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
