Bug in SRT generation for procs in .cmm files?

Ben Gamari ben at well-typed.com
Thu Jan 23 12:15:53 UTC 2020

While it's true that in principle one could imagine a case where you would want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today.  Consequently it wouldn't surprise me if this was broken.

Frankly, I wouldn't worry too much about this if it's nontrivial to fix. 


 - Ben 

On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" <omeragacan at gmail.com> wrote:
>Hi Simon,
>Currently CmmParse only generates CmmLabels for procs, and those are
>non-CAFFY by hasCAF (and thus CmmBuildInfoTables).
>As a result if I have two procs in a .cmm file:
>- p1, refers to a CAF in base
>- p2, refers to p1
>I *think* (haven't checked) we don't consider p1 as CAFFY, and even if
>we do, we
>don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be
>considered CAFFY by hasCAF.
>So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT
>will never build SRTs for procs in .cmm files.
>Is this intentional? I'd expect this to be possible, because there's
>preventing me from referring to a CAFFY definition in a library (e.g.
>base) in a
>.cmm file, but doing this would be a bug in runtime.
>ghc-devs mailing list
>ghc-devs at haskell.org

Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200123/3b47ff5c/attachment.html>

More information about the ghc-devs mailing list