Uros Bizjak writes:
> BTW: I'd like to point out that we can use go-execute-xfail in this
> case, so the case is compiled but is known to fail execution for some
> reason.
Thanks, I didn't know about that one.
I think I'll leave it as is for now because I'm treating stack.go the
same way, and s
On Thu, Feb 9, 2012 at 7:43 AM, Ian Lance Taylor wrote:
> Uros Bizjak writes:
>
>> Some more debugging reveal the difference between alpha and x86_64.
>> Alpha does not implement split stacks, so soon after
>> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
>> via:
>
> Thank
Uros Bizjak writes:
> Some more debugging reveal the difference between alpha and x86_64.
> Alpha does not implement split stacks, so soon after
> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
> via:
Thanks for tracking this down.
> So, short of XFAILing the test on non-
On Wed, Feb 1, 2012 at 10:59 PM, Uros Bizjak wrote:
> On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor wrote:
>
>>> (BTW: Do you have any idea on what to do with excessive memory usage
>>> in chan/select2.go? )
>>
>> At this point I don't. It's sort of peculiar. Sending an int on a
>> channel
On Wed, Feb 1, 2012 at 10:27 PM, Ian Lance Taylor wrote:
>> (BTW: Do you have any idea on what to do with excessive memory usage
>> in chan/select2.go? )
>
> At this point I don't. It's sort of peculiar. Sending an int on a
> channel should not use any memory. The test is careful to only measu
