Excerpts from Simon Marlow's message of Mon Mar 14 10:06:28 -0400 2011:
> I'm afraid I'm not familiar enough with the code (yet) to answer this
> one, sorry. Can you turn on enough logging to find out what's going on?
I figured it out and submitted a patch!
Cheers,
Edward
_
On 11/03/2011 02:57, Edward Z. Yang wrote:
It looks like this change causes the assignment to be emitted before
the initial assignment, which is all quite puzzling to me.
I'm afraid I'm not familiar enough with the code (yet) to answer this
one, sorry. Can you turn on enough logging to find o
It looks like this change causes the assignment to be emitted before
the initial assignment, which is all quite puzzling to me.
Edward
Excerpts from Edward Z. Yang's message of Wed Mar 09 20:46:12 -0500 2011:
> OK, I looked more closely at my previous attempted solution, but I couldn't
> get it t
OK, I looked more closely at my previous attempted solution, but I couldn't
get it to work:
regIdInfo :: Id -> LambdaFormInfo -> LocalReg -> FCode CgIdInfo
regIdInfo id lf_info reg = do
emit $ mkAssign (CmmLocal reg) (addDynTag (CmmReg (CmmLocal reg))
(lfDynTag lf_info))
retur
Hi Edward,
Well done for tracking down the bug!
On 06/03/11 15:36, Edward Z. Yang wrote:
Excerpts from Edward Z. Yang's message of Sat Mar 05 15:00:03 -0500 2011:
2. Change the code generator to not do untagged spills.
I tried a brief patch to do this, but the result segfaulted, and I d
Excerpts from Edward Z. Yang's message of Sat Mar 05 15:00:03 -0500 2011:
> 2. Change the code generator to not do untagged spills.
I tried a brief patch to do this, but the result segfaulted, and I decided
(1) might be more fruitful.
> 1. Investigate the operation of the compacting GC mo
OK, in that case, here is what I think is the bug: under circumstances, we can
make an assignment to a temporary variable a pointer to a variable on the heap,
which will be tagged later in the code. Subsequent optimization passes result
in this untagged variable being spilled on to the stack. The
On 20/02/2011 00:57, Edward Z. Yang wrote:
If I have the following program:
import Bagel
main = do
l<- getContents
length l `seq` putStr (sort l)
with sort defined in the module Bagel as such:
module Bagel where
-- a bastardized version of sort that still
ng GC interacting with new codegen strangely
|
| If I have the following program:
|
| import Bagel
|
| main = do
| l <- getContents
| length l `seq` putStr (sort l)
|
| with sort defined in the module Bagel as such:
|
| module Bagel where
| -- a bastardized version
Thanks for your reply!
Excerpts from Ben Lippmeier's message of Sun Feb 20 18:57:30 -0500 2011:
> As you suggest, it may well be a bug in the runtime system or libraries due
> to not untagging pointers. I have fixed a few of these myself. The
> hard-and-fast rule is that all pointers from the heap
On 20/02/2011, at 11:57 AM, Edward Z. Yang wrote:
>
> If I:
>
>- Turn off compacting GC
>- Reduce the size of master-data
>- Turn off optimizations
>- Use the old codegen
>- Put all of the code in one file
>- Remove the seqs from 'sort' (which isn't actually a sort)
>
If I have the following program:
import Bagel
main = do
l <- getContents
length l `seq` putStr (sort l)
with sort defined in the module Bagel as such:
module Bagel where
-- a bastardized version of sort that still exhibits the bug
sort :: Ord a => [a] -> [a]
12 matches
Mail list logo
