#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: new
Priority: normal
#5015: Can't unsafeCoerce a GADT with a coercion
-+--
Reporter: TristanAllwood| Owner:
Type: bug | Status: new
Priority: normal
#5015: Can't unsafeCoerce a GADT with a coercion
--+-
Reporter: TristanAllwood | Owner:
Type: bug | Status: closed
Priority: normal
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
--+-
Reporter: ekmett | Owner:
Type: feature request | Status: closed
Priority
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
-+--
Reporter: ekmett| Owner:
Type: feature request | Status: new
Priority: normal
#4166: unsafeCoerce#'s kind is not as liberal enough to inspect tag bits.
-+--
Reporter: ekmett| Owner:
Type: feature request | Status: new
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: 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
#3948: unsafeCoerce leaks types
---+
Reporter: ksf | Owner:
Type: bug | Status: new
Priority: normal | Component: Template
#3949: unsafeCoerce leaks types
---+
Reporter: ksf | Owner:
Type: bug | Status: new
Priority: normal | Component: Template
#3949: unsafeCoerce leaks types
-+--
Reporter: ksf | Owner:
Type: bug | Status: closed
Priority: normal| Component: Template Haskell
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: closed
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: closed
Priority: normal
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: normal
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: normal
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: normal
#1482: unsafeCoerce# doesn't always fully coerce
+---
Reporter: [EMAIL PROTECTED] |Owner:
Type: bug | Status: new
Priority: normal
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
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
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
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
--+-
Reporter: [EMAIL PROTECTED] | Owner:
Type: feature request| Status: new
Priority
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
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 Behalf
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-
| From: [EMAIL PROTECTED]
[mailto
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 suggested GHC.Base
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), which I guessed
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 unsafeCoerce# should never
cause type-incorrect C or asm 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
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
$ ./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
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 *, and f
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# :: forall b a. a - b
The type variables a and b
39 matches
Mail list logo
