let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?

[Carter Schonwald]

ok, i'm getting a let/app invariant failure when i build my test case with
O1 or O2 but not without

http://lpaste.net/114881

any help would be appreciated on how to address that

On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> yup, i have that!
>
>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>
> in the test suite!
>
> in contrast
>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
> does explode
>
> shall I add a "should fail" test with the latter? (it doesn't seem
> worthwhile)
>
> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Maybe test for laziness in the argument by just putting something in that
>> goes boom when forced, e.g. 'undefined'?
>>
>>
>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Hey All,
>>> as part of trying to get some fixups for how prefetch works into 7.10,
>>> i'm adding a "prefetchValue" primop that prefetchs the memory location
>>> of a lifted heap value
>>>
>>> namely
>>>
>>> several operations of the following form
>>>
>>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>>    a -> State# s -> State# s
>>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>>> topRes }
>>>
>>> I'd like some feedback on the strictness information design by someone
>>> who's familiar with how that piece of GHC. the idea being that
>>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>>> just does a prefetch on the heap location, which may or may not be
>>> evaluated).
>>>
>>> https://phabricator.haskell.org/D350
>>>
>>> is the code in question. And i *believe* i'm testing for being lazy in
>>> that argument correctly.
>>>
>>> thoughts?
>>>
>>> many thanks!
>>> -Carter
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/18d30211/attachment.html>