remAddr# primop inconsistency

[Csaba Hruska]

Great, thanks!

On Sat, Feb 6, 2021 at 5:04 PM Ben Gamari <ben at well-typed.com> wrote:

> Csaba Hruska <csaba.hruska at gmail.com> writes:
>
> > Hello,
> >
> > I've discovered that the remAddr# primop documentation is inconsistent
> with
> > the implementation.
> > According to the docs (primops.txt.pp) the remAddr# should be the same as
> > remInt#.
> >
> >> primop   AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int#
>  {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt
> Int\#},          is divided by the {\tt Int\#} arg.}
> >>
> >> But it is implemented with the mo_wordURem instruction, just like the
> > WordRemOp primop.
> >
> >> GHC/StgToCmm/Prim.hs:
> >>
> > AddrRemOp -> \args -> opTranslate args (mo_wordURem platform)
> >>
> > WordRemOp -> \args -> opTranslate args (mo_wordURem platform)
> >>
> > IntRemOp -> \args -> opTranslate args (mo_wordSRem platform)
> >>
> >
> > Which one is correct, the docs or the implementation?
>
> That is a good question. The only user (in the GHC tree) is
> GHC.Ptr.alignPtr which appears to want the Word semantics (that is, it
> would break given a negative remainder). Moreover, my mental model of
> pointers is that for the purposes of arithmetic they are non-negative.
> Therefore, I belive that the documentation here is wrong.
>
> I have opened #19332 to track this.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210206/9361cd43/attachment.html>