Re: constant pooling in GHC
I simply mean that the same constant is not emitted more than once to memory. I.e. If a constant string is used twice, there is only one value in .rodata for it. On Fri, Sep 21, 2018, 01:20 Carter Schonwald wrote: > what precisely do you mean by constant pooling? i can guess several > meanings, but what do you mean specifically? > > On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: > >> Hi All, >> >> I'm hoping someone here can save me some time. I'm working on something >> that relies on constants in the same translation unit being pooled before >> assembly. >> >> I've noticed GHC does some const pooling at -O1 , but this doesn't seem >> to be very consistent, which leads me to believe this is a byproduct of >> another optimization rather than an explicit thing. >> >> I couldn't find anything obvious in the sources, so does GHC >> intentionally do constant pooling already? Or do I need a new pass to >> guarantee it. >> >> Thanks, >> Tamar >> > ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: constant pooling in GHC
what precisely do you mean by constant pooling? i can guess several meanings, but what do you mean specifically? On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: > Hi All, > > I'm hoping someone here can save me some time. I'm working on something > that relies on constants in the same translation unit being pooled before > assembly. > > I've noticed GHC does some const pooling at -O1 , but this doesn't seem to > be very consistent, which leads me to believe this is a byproduct of > another optimization rather than an explicit thing. > > I couldn't find anything obvious in the sources, so does GHC intentionally > do constant pooling already? Or do I need a new pass to guarantee it. > > Thanks, > Tamar > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Windows testsuite failures
Hi Simon, Thanks for the email. I haven't been building head much as I'm working on top of some older commits. From a quick look it seems like the plugin ones are probably testisms, the plugins aren't found so likely a missing path entry somewhere. The linker ones are are weird, I'll need to take a closer look at those, likely culprit is my recent patch, I had been testing in the 32 bit build and didn't notice these. There are a few worrying segfault that shouldn't be there on some random tests so I'll take a closer look at those too. And the stat changes need to be updated. The framework failures I don't see on harbormaster, so think they are again a threading artifact. Need to figure out a more effective way to debug these to find a permanent fix. The ones that harbormaster does see are encoding related. touch is failing on non-ascii names. I will take a look this weekend. Kind regards, Tamar On Thu, Sep 20, 2018, 11:33 Simon Peyton Jones wrote: > Hi Tamar > > The list of testsuite failure on Windows has grown quite long – see > below. Most seem to concern plugins or linking. > > Do you know what is going on here? If they can’t be fixed, can we mark > them as expect_broken on Windows, so that it’s easier (when developing) to > know when I’ve introduced a regression. Currently I have to do a manual > diff against a rather long list. > > Thanks! > > Simon > > > > *SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST* > > *1:03:11 spent to go through* > > *6530 total tests, which gave rise to* > > * 18728 test cases, of which* > > * 12206 were skipped* > > > > * 33 had missing libraries* > > *6278 expected passes* > > * 173 expected failures* > > > > * 9 caused framework failures* > > * 1 caused framework warnings* > > * 0 unexpected passes* > > * 31 unexpected failures* > > * 7 unexpected stat failures* > > > > *Unexpected failures:* > > * ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] > (normal)* > > * ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci)* > > * ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] > (normal)* > > * numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] > (normal)* > > * plugins/T11244.run T11244 [bad stderr] (normal)* > > * plugins/plugin-recomp-change.runplugin-recomp-change [bad exit > code] (normal)* > > * rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci)* > > * rts/linker_unload.run linker_unload [bad exit code] > (normal)* > > * rts/linker_error1.run linker_error1 [bad exit code] > (normal)* > > * rts/linker_error2.run linker_error2 [bad exit code] > (normal)* > > * rts/T12771/T12771.run T12771 [bad exit code] > (normal)* > > * rts/T13082/T13082_good.run T13082_good [bad exit code] > (normal)* > > * rts/T14611/T14611.run T14611 [bad exit code] > (normal)* > > * simplCore/should_compile/T7702.run T7702 [exit code non-0] > (normal)* > > * rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal)* > > * libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal)* > > * plugins/plugins01.run plugins01 [bad exit code] > (normal)* > > * plugins/plugins07.run plugins07 [bad exit code] > (normal)* > > * plugins/plugins09.run plugins09 [bad exit code] > (normal)* > > * plugins/plugins11.run plugins11 [bad exit code] > (normal)* > > * plugins/plugins12.run plugins12 [bad exit code] > (normal)* > > * plugins/plugins13.run plugins13 [bad exit code] > (normal)* > > * plugins/plugins14.run plugins14 [bad exit code] > (normal)* > > * plugins/plugins15.run plugins15 [bad exit code] > (normal)* > > * plugins/T10420.run T10420 [bad exit code] > (normal)* > > * plugins/T10294.run T10294 [bad exit code] > (normal)* > > * plugins/T10294a.run T10294a [bad exit code] > (normal)* > > * plugins/T12567a.run T12567a [bad exit code] > (normal)* > > * plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit > code] (normal)* > > * plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit > code] (normal)* > > * plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit > code] (normal)* > > > > *Unexpected stat failures:* > > * perf/compiler/T9872d.run T9872d [stat not good enough] > (normal)* > > * perf/compiler/T12425.run T12425 [stat not good enough] > (optasm)* > > * perf/compiler/T12234.run T12234 [stat not good enough] > (optasm)* > > * perf/compiler/T12150.run T12150 [stat not good enough] > (optasm)*
Windows testsuite failures
Hi Tamar The list of testsuite failure on Windows has grown quite long - see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can't be fixed, can we mark them as expect_broken on Windows, so that it's easier (when developing) to know when I've introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.runplugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.runplugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.runT11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.runT10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.runplugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
> Are you saying allocateMightFail ignores the usual nursery size?
Right, so normally in Cmm you'd do something like `if (Hp + size > HpLim) {
trigger GC }`, but allocateMightFail adds more blocks to the nursery instead.
Maybe just look at the code, it's quite simple.
I don't know how to check Hp in the RTS and trigger a GC. I'd do that part in
Cmm as there are lots of Cmm functions that do this already (in PrimOps.cmm
and maybe elsewhere).
Ömer
David Feuer , 20 Eyl 2018 Per, 12:50 tarihinde
şunu yazdı:
>
> I'm not sure I understand. Are you saying allocateMightFail ignores the usual
> nursery size? That's not my intention. It would actually be just fine to
> simply fail if GC would be required--I can then back off, fail out to CMM,
> trigger a GC there, and retry. Or I could perform an extra heap check before
> I start; that's a little silly, but I doubt it'll be expensive enough to
> really matter here.
>
> On Thu, Sep 20, 2018, 5:42 AM Ömer Sinan Ağacan wrote:
>>
>> allocateMightFail allocates new nursery blocks as long as you don't hit the
>> heap limit, so it returns NULL less often than you might think. In
>> particular,
>> it doesn't return NULL when the nursery is full, instead it allocates a new
>> block and adds it to the nursery.
>>
>> I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure
>> if
>> it's possible to do this in C code. There should be some functions in
>> PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of
>> ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least
>> give
>> an idea of how a GC is triggered).
>>
>> Ömer
>>
>> David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde
>> şunu yazdı:
>> >
>> > If it returns NULL, then I need to back off what I'm doing and trigger a
>> > GC. How do I do the latter?
>> >
>> > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan
>> > wrote:
>> >>
>> >> allocateMightFail does the heap check for you and returns NULL. For the
>> >> current
>> >> capability you can use MyCapability() in Cmm and pass the value to the RTS
>> >> function you're implementing.
>> >>
>> >> Ömer
>> >>
>> >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde
>> >> şunu yazdı:
>> >> >
>> >> > Aha! Okay. How do I get the current capability to pass to that? I guess
>> >> > I should probably perform a heap check before calling lookupSta bleName
>> >> > for simplicity, at least to start.
>> >> >
>> >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan
>> >> > wrote:
>> >> >>
>> >> >> Have you seen Storage.c:allocateMightFail ?
>> >> >>
>> >> >> Ömer
>> >> >>
>> >> >>
>> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde
>> >> >> şunu yazdı:
>> >> >> >
>> >> >> > I'm working on re-implementing the stable name system. For the new
>> >> >> > design, it seems much cleaner to allocate stable names in
>> >> >> > lookupStableName (in rts/StableName.c) rather than in the C-- code
>> >> >> > that calls it. But I haven't seen RTS code that does heap
>> >> >> > allocation. Is it possible? If so, how do I do it?
>> >> >> > ___
>> >> >> > ghc-devs mailing list
>> >> >> > ghc-devs@haskell.org
>> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
I'm not sure I understand. Are you saying allocateMightFail ignores the usual nursery size? That's not my intention. It would actually be just fine to simply fail if GC would be required--I can then back off, fail out to CMM, trigger a GC there, and retry. Or I could perform an extra heap check before I start; that's a little silly, but I doubt it'll be expensive enough to really matter here. On Thu, Sep 20, 2018, 5:42 AM Ömer Sinan Ağacan wrote: > allocateMightFail allocates new nursery blocks as long as you don't hit the > heap limit, so it returns NULL less often than you might think. In > particular, > it doesn't return NULL when the nursery is full, instead it allocates a new > block and adds it to the nursery. > > I'd do the GC triggering part in Cmm code instead of C code -- I'm not > sure if > it's possible to do this in C code. There should be some functions in > PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of > ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least > give > an idea of how a GC is triggered). > > Ömer > > David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde > şunu yazdı: > > > > If it returns NULL, then I need to back off what I'm doing and trigger a > GC. How do I do the latter? > > > > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan > wrote: > >> > >> allocateMightFail does the heap check for you and returns NULL. For the > current > >> capability you can use MyCapability() in Cmm and pass the value to the > RTS > >> function you're implementing. > >> > >> Ömer > >> > >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde > >> şunu yazdı: > >> > > >> > Aha! Okay. How do I get the current capability to pass to that? I > guess I should probably perform a heap check before calling lookupSta > bleName for simplicity, at least to start. > >> > > >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan > wrote: > >> >> > >> >> Have you seen Storage.c:allocateMightFail ? > >> >> > >> >> Ömer > >> >> > >> >> > >> >> David Feuer , 20 Eyl 2018 Per, 11:32 > tarihinde > >> >> şunu yazdı: > >> >> > > >> >> > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > >> >> > ___ > >> >> > ghc-devs mailing list > >> >> > ghc-devs@haskell.org > >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
allocateMightFail allocates new nursery blocks as long as you don't hit the heap limit, so it returns NULL less often than you might think. In particular, it doesn't return NULL when the nursery is full, instead it allocates a new block and adds it to the nursery. I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure if it's possible to do this in C code. There should be some functions in PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least give an idea of how a GC is triggered). Ömer David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde şunu yazdı: > > If it returns NULL, then I need to back off what I'm doing and trigger a GC. > How do I do the latter? > > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan wrote: >> >> allocateMightFail does the heap check for you and returns NULL. For the >> current >> capability you can use MyCapability() in Cmm and pass the value to the RTS >> function you're implementing. >> >> Ömer >> >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde >> şunu yazdı: >> > >> > Aha! Okay. How do I get the current capability to pass to that? I guess I >> > should probably perform a heap check before calling lookupSta bleName for >> > simplicity, at least to start. >> > >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan >> > wrote: >> >> >> >> Have you seen Storage.c:allocateMightFail ? >> >> >> >> Ömer >> >> >> >> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde >> >> şunu yazdı: >> >> > >> >> > I'm working on re-implementing the stable name system. For the new >> >> > design, it seems much cleaner to allocate stable names in >> >> > lookupStableName (in rts/StableName.c) rather than in the C-- code that >> >> > calls it. But I haven't seen RTS code that does heap allocation. Is it >> >> > possible? If so, how do I do it? >> >> > ___ >> >> > ghc-devs mailing list >> >> > ghc-devs@haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
If it returns NULL, then I need to back off what I'm doing and trigger a GC. How do I do the latter? On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan wrote: > allocateMightFail does the heap check for you and returns NULL. For the > current > capability you can use MyCapability() in Cmm and pass the value to the RTS > function you're implementing. > > Ömer > > David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde > şunu yazdı: > > > > Aha! Okay. How do I get the current capability to pass to that? I guess > I should probably perform a heap check before calling lookupSta bleName for > simplicity, at least to start. > > > > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan > wrote: > >> > >> Have you seen Storage.c:allocateMightFail ? > >> > >> Ömer > >> > >> > >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde > >> şunu yazdı: > >> > > >> > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > >> > ___ > >> > ghc-devs mailing list > >> > ghc-devs@haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
allocateMightFail does the heap check for you and returns NULL. For the current capability you can use MyCapability() in Cmm and pass the value to the RTS function you're implementing. Ömer David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde şunu yazdı: > > Aha! Okay. How do I get the current capability to pass to that? I guess I > should probably perform a heap check before calling lookupSta bleName for > simplicity, at least to start. > > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: >> >> Have you seen Storage.c:allocateMightFail ? >> >> Ömer >> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde >> şunu yazdı: >> > >> > I'm working on re-implementing the stable name system. For the new design, >> > it seems much cleaner to allocate stable names in lookupStableName (in >> > rts/StableName.c) rather than in the C-- code that calls it. But I haven't >> > seen RTS code that does heap allocation. Is it possible? If so, how do I >> > do it? >> > ___ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start. On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: > Have you seen Storage.c:allocateMightFail ? > > Ömer > > > David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde > şunu yazdı: > > > > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Heap allocation in the RTS
Have you seen Storage.c:allocateMightFail ? Ömer David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde şunu yazdı: > > I'm working on re-implementing the stable name system. For the new design, it > seems much cleaner to allocate stable names in lookupStableName (in > rts/StableName.c) rather than in the C-- code that calls it. But I haven't > seen RTS code that does heap allocation. Is it possible? If so, how do I do > it? > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Heap allocation in the RTS
I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
