1. 31 Oct, 2014 4 commits
    • Austin Clements's avatar
      [dev.power64] runtime: fix gcinfo_test on power64x · e1db508f
      Austin Clements authored
      The GC info masks for slices and strings were changed in
      commit caab29a25f68, but the reference masks used by
      gcinfo_test for power64x hadn't caught up.  Now they're
      identical to amd64, so this CL fixes this test by combining
      the reference masks for these platforms.
      
      LGTM=rsc
      R=rsc, dave
      CC=golang-codereviews
      https://golang.org/cl/162620044
      e1db508f
    • Austin Clements's avatar
      [dev.power64] reflect: fix asm on power64x · 700ab16d
      Austin Clements authored
      reflect/asm_power64x.s was missing changes made to other
      platforms for stack maps.  This CL ports those changes.  With
      this fix, the reflect test passes on power64x.
      
      LGTM=rsc
      R=rsc, dave
      CC=golang-codereviews
      https://golang.org/cl/170870043
      700ab16d
    • Austin Clements's avatar
      [dev.power64] runtime: fix fastrand1 on power64x · 40a5b3ec
      Austin Clements authored
      fastrand1 depends on testing the high bit of its uint32 state.
      For efficiency, all of the architectures implement this as a
      sign bit test.  However, on power64, fastrand1 was using a
      64-bit sign test on the zero-extended 32-bit state.  This
      always failed, causing fastrand1 to have very short periods
      and often decay to 0 and get stuck.
      
      Fix this by using a 32-bit signed compare instead of a 64-bit
      compare.  This fixes various tests for the randomization of
      select of map iteration.
      
      LGTM=rsc
      R=rsc, dave
      CC=golang-codereviews
      https://golang.org/cl/166990043
      40a5b3ec
    • Austin Clements's avatar
      [dev.power64] 9g: fix under-zeroing in clearfat · 6e860036
      Austin Clements authored
      All three cases of clearfat were wrong on power64x.
      
      The cases that handle 1032 bytes and up and 32 bytes and up
      both use MOVDU (one directly generated in a loop and the other
      via duffzero), which leaves the pointer register pointing at
      the *last written* address.  The generated code was not
      accounting for this, so the byte fill loop was re-zeroing the
      last zeroed dword, rather than the bytes following the last
      zeroed dword.  Fix this by simply adding an additional 8 byte
      offset to the byte zeroing loop.
      
      The case that handled under 32 bytes was also wrong.  It
      didn't update the pointer register at all, so the byte zeroing
      loop was simply re-zeroing the beginning of region.  Again,
      the fix is to add an offset to the byte zeroing loop to
      account for this.
      
      LGTM=dave, bradfitz
      R=rsc, dave, bradfitz
      CC=golang-codereviews
      https://golang.org/cl/168870043
      6e860036
  2. 30 Oct, 2014 5 commits
  3. 29 Oct, 2014 13 commits
  4. 28 Oct, 2014 18 commits