On Mon, 11 Jan 2016 13:51:25 -0700
Tom Tromey wrote:
> > "Michael" == Michael Matz writes:
>
> Michael> Well, that's a hack. A solution is to design something that
> Michael> works generally for garbage collected languages with such
> Michael> requirements instead of arbitrarily limiting
> "Michael" == Michael Matz writes:
Michael> Well, that's a hack. A solution is to design something that
Michael> works generally for garbage collected languages with such
Michael> requirements instead of arbitrarily limiting transformations
Michael> here and there. It could be something li
On January 11, 2016 8:35:25 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>On Mon, 11 Jan 2016, Ian Lance Taylor wrote:
>
>> > Well, that's a hack. A solution is to design something that works
>> > generally for garbage collected languages with such requirements
>> > instead of arbitrarily limiting
Hi,
On Mon, 11 Jan 2016, Ian Lance Taylor wrote:
> > Well, that's a hack. A solution is to design something that works
> > generally for garbage collected languages with such requirements
> > instead of arbitrarily limiting transformations here and there. It
> > could be something like the n
On Mon, Jan 11, 2016 at 10:00 AM, Michael Matz wrote:
>
> On Fri, 8 Jan 2016, Richard Biener wrote:
>
>> > The only solution here is for ivopts to keep a pointer to the array,
>> > not a pointer to some location near, but outside of the array.
>>
>> Yes, the solution is to make IVOPTs not do this
Hi,
On Fri, 8 Jan 2016, Richard Biener wrote:
> > The only solution here is for ivopts to keep a pointer to the array,
> > not a pointer to some location near, but outside of the array.
>
> Yes, the solution is to make IVOPTs not do this (eventually controlled
> by a parameter because clearly
On Wed, Jan 6, 2016 at 4:26 PM, Jeff Law wrote:
> On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
>>
>> The bug report https://golang.org/issue/13662 describes a case in
>> which ivopts appears to be breaking garbage collection for the Go
>> compiler. There is an array allocated in memory, and th
On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
The bug report https://golang.org/issue/13662 describes a case in
which ivopts appears to be breaking garbage collection for the Go
compiler. There is an array allocated in memory, and there is a loop
over that array. The ivopts optimization is ta
The bug report https://golang.org/issue/13662 describes a case in
which ivopts appears to be breaking garbage collection for the Go
compiler. There is an array allocated in memory, and there is a loop
over that array. The ivopts optimization is taking the only pointer
to the array and subtracting
