#6162: defer-type-errors + unsafeCoerce
---+
Reporter: guest | Owner:
Type: feature request | Status: closed
Priority: normal
#6162: defer-type-errors + unsafeCoerce
--+-
Reporter: guest | Owner:
Type: feature request| Status: new
Priority: normal | Milestone
#6162: defer-type-errors + unsafeCoerce
--+-
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal| Component
#5015: Can't unsafeCoerce a GADT with a coercion
--+-
Reporter: TristanAllwood | Owner:
Type: bug | Status: closed
Priority: n
#5015: Can't unsafeCoerce a GADT with a coercion
-+--
Reporter: TristanAllwood| Owner:
Type: bug | Status: new
Priority: n
#5015: Can't unsafeCoerce a GADT with a coercion
-+--
Reporter: TristanAllwood| Owner:
Type: bug | Status: new
Priority: n
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
--+-
Reporter: ekmett | Owner:
Type: feature request | Status: closed
Pri
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
-+--
Reporter: ekmett| Owner:
Type: feature request | Status: new
Priority: n
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
-+--
Reporter: ekmett| Owner:
Type: feature request | Status: new
Priority: n
#4090: Impossible compilation with primitive operations (possibly unsafeCoerce#)
-+--
Reporter: malosh | Owner:
Type: bug | Status: closed
Priority: normal
#4090: Impossible compilation with primitive operations (possibly unsafeCoerce#)
-+--
Reporter: malosh | Owner:
Type: bug | Status: closed
Priority: normal
#4090: Impossible compilation with primitive operations (possibly unsafeCoerce#)
+---
Reporter: malosh | Owner:
Type: bug | Status: new
Priority: normal
#4090: Impossible compilation with primitive operations (possibly unsafeCoerce#)
+---
Reporter: malosh | Owner:
Type: bug | Status: new
Priority: normal
#3948: unsafeCoerce leaks types
---+
Reporter: ksf | Owner:
Type: bug | Status: closed
Priority: normal| Milestone
#3949: unsafeCoerce leaks types
-+--
Reporter: ksf | Owner:
Type: bug | Status: closed
Priority: normal| Component: Template Haskell
#3949: unsafeCoerce leaks types
---+
Reporter: ksf | Owner:
Type: bug | Status: new
Priority: normal | Component: Template
#3948: unsafeCoerce leaks types
---+
Reporter: ksf | Owner:
Type: bug | Status: new
Priority: normal | Component: Template
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Statu
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: closed
Priority: n
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: n
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: n
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: n
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: n
#1482: unsafeCoerce# doesn't always fully coerce
--+-
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: n
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | St
jhc calls it unsafeCoerce__ and it lives in Jhc.Prim. In general, I use
the trailing __ to mean what abafthash does in ghc.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://
Hello GHC,
Monday, November 13, 2006, 3:18:13 PM, you wrote:
> Unsafe.Coerce. Later proposals might want to move some of the Array and
> IO operations into this new Unsafe.* hierarchy as well.
it seems that you misunderstood situation: you will need to move whole
Array implementation to such
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | St
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | St
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | St
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | St
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
--+-
Reporter: [EMAIL PROTECTED] | Owner:
Type: feature request| Status: new
/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
Good idea. There's suitable section here in the HEAD manual, here:
http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.htm
l#id3159468
I'll add a subsection about unsafeCoerce#
Simon
| -Original Message
Good idea. There's suitable section here in the HEAD manual, here:
http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.htm
l#id3159468
I'll add a subsection about unsafeCoerce#
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
|
On 7/31/06, Neil Mitchell <[EMAIL PROTECTED]> wrote:
Hi,
Finding unsafeCoerce# in the documentation is challenging at best.
It's not indexed by Haddock, which in turn means its not indexed by
Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an
old Happy file),
Hi,
Finding unsafeCoerce# in the documentation is challenging at best.
It's not indexed by Haddock, which in turn means its not indexed by
Hoogle. Lambdabot doesn't find it. Googling gave me GhcExts (from an
old Happy file), which I guessed at GHC.Exts.
Someone in #haskell suggeste
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 inl
rated 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 i
hci).
>
> When working it runs and produces the following (correct) result:
>
> paprika$ ./a.out
> .0
> (69,243,8,0)
> .0
>
> However, if I turn on -O it fails to generate acceptable asm or C.
>
> Am I right in thinking that all uses of unsafe
wolfgang.thaller:
> >g (F# f) =
> >let w = W32# (unsafeCoerce# f)
>
> Why does GHC even accept this code?
> I think unsafeCoerce# is not intended to be able to coerce unboxed
> values.
>
> Prelude GHC.Base> :t unsafeCoerce#
> unsafeCoerce#
g (F# f) =
let w = W32# (unsafeCoerce# f)
Why does GHC even accept this code?
I think unsafeCoerce# is not intended to be able to coerce unboxed
values.
Prelude GHC.Base> :t unsafeCoerce#
unsafeCoerce# :: forall b a. a -> b
The type variables a and b are supposed to be of kind
$ ./a.out
.0
(69,243,8,0)
.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
42 matches
Mail list logo
