[GHC] #7684: cgrun071 segfaults

[Johan Tibell]

I don't think we should. We should either call the C based fallback
implementation in the ghc-prim package or the popcnt instruction. The
Haskell implementation in the test is a toy that should only be used
to validate that the primop computes the right result. If the
instruction is being incorrectly used when it's not available we
should fix that.

On Thu, Sep 5, 2013 at 9:47 AM, Muhaimin Ahsan <leroux at fezrev.com> wrote:
> I'm asking if we should call it in the real implementation of the PrimOp. This isn't a problem across all platforms; it's specific to apple-gcc42, I believe based on yesterday's findings. I'll continue working on it later today. Also, I'm extremely new to GHC internals (this is the second bug I'm tackling), so I may be viewing things the wrong and would appreciate pointers.
>
> Muhaimin Ahsan
>
> On Sep 5, 2013, at 9:09 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> On Thu, Sep 5, 2013 at 12:20 AM, GHC <ghc-devs at haskell.org> wrote:
>>> Should we switch to calling the "slower" popCount for this certain case?
>>> https://github.com/ghc/testsuite/blob/master/tests/codeGen/should_run/cgrun071.hs#L41-L46
>>> {{{
>>> slowPopcnt :: Word -> Word
>>> slowPopcnt x = count' (bitSize x) x 0
>>>   where
>>>     count' 0 _ !acc = acc
>>>     count' n x acc  = count' (n-1) (x `shiftR` 1)
>>>                       (acc + if x .&. 1 == 1 then 1 else 0)
>>> }}}
>>
>> I've not been following this closely so apologies if I've
>> misunderstood the issue.
>>
>> Are you asking if we should call slowPopcnt in the test in more
>> circumstances or if we should call it in the real implementation of
>> the primop? The primop already has a fallback if the popcnt
>> instruction isn't available (it uses a table-based implementation).
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>