Bug in SRT generation for procs in .cmm files?

[Ben Gamari]

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. 

Cheers, 

 - 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
>considered
>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
>algorithm
>will never build SRTs for procs in .cmm files.
>
>Is this intentional? I'd expect this to be possible, because there's
>nothing
>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.
>
>Thanks,
>
>Ömer
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
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>