libgo patch committed: Copy hash code from Go 1.7 runtime

[Rainer Orth]

Hi Ian,

> This patch to libgo copies the memory hashing code from the Go 1.7
> runtime.  This is particular important because we earlier copied the
> hashmap code from Go 1.7, and that changed hash table sizes from prime
> numbers to powers of two.  The memory hashing code used before this
> patch was fine for prime numbers but for powers of two tended to hash
> many values to the same bucket, making maps much much slower than they
> should be.
>
> I rewrote the AES hashing code from gc assembler to C code using
> intrinsics.  The resulting code generates the same hash code for the
> same input as the gc code--that doesn't matter as such, but testing it
> ensures that the C code does something useful.
>
> I changed mips64pe32le to mips64p32le in configure script--noticed
> during CL review.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, both with
> and without the AES hashing code.  Committed to mainline.

this broke Solaris in two different ways:

* On both sparc and x86, libgo fails to compile:

In file included from /vol/gcc/src/hg/trunk/local/libgo/runtime/runtime.h:114:0,
                 from /vol/gcc/src/hg/trunk/local/libgo/runtime/aeshash.c:7:
./runtime.inc:8:12: error: expected identifier or '(' before numeric constant
 #define m1 3168982561
            ^
./runtime.inc:782:11: note: in expansion of macro 'm1'
  uint32_t m1;
           ^~
./runtime.inc:9:12: error: expected identifier or '(' before numeric constant
 #define m2 3339683297
            ^
./runtime.inc:783:11: note: in expansion of macro 'm2'
  uint32_t m2;
           ^~
./runtime.inc:10:12: error: expected identifier or '(' before numeric constant
 #define m3 832293441
            ^
./runtime.inc:784:11: note: in expansion of macro 'm3'
  uint32_t m3;
           ^~
./runtime.inc:11:12: error: expected identifier or '(' before numeric constant
 #define m4 2336365089
            ^
./runtime.inc:785:11: note: in expansion of macro 'm4'
  uint32_t m4;
           ^~

  This is similar to what we had with c[01] before, and fixed in the
  same way:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sol2-libgo-aeshash.patch
Type: text/x-patch
Size: 704 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20161209/1aa0062a/attachment.bin>
-------------- next part --------------

* Once the build completes, on Solaris/x86 with /bin/as every single Go
  execution test FAILs:

ld.so.1: a.out: fatal: /var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/libgo/.libs/libgo.so.10: hardware capability (CA_SUNW_HW_1) unsupported: 0x4400000  [ AES SSSE3 ]
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[638]: wait: 19831: Killed
/vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[643]: wait: 19832: Terminated
/bin/ksh: 9035: Killed
FAIL: bufio

ld.so.1: array-1.x: fatal: /var/gcc/regression/trunk/12-gcc/build/i386-pc-solaris2.12/./libgo/.libs/libgo.so.10: hardware capability (CA_SUNW_HW_1) unsupported: 0x4400000  [ AES SSSE3 ]
FAIL: go.go-torture/execute/array-1.go execution,  -O0

  Again, this is a known issue, previously in libitm and recently in
  libgfortran.  The latter is fixed by my (still unreviewed) patch

	https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html

  and can be fixed for libgo along the same lines (on top of the
  libgfortran etc. one):

2016-12-09  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* configure.ac: Call GCC_CHECK_LINKER_HWCAP.
	* Makefile.am (AM_LDFLAGS): Initialize to HWCAP_LDFLAGS.
	[USING_SPLIT_STACK]: Add to AM_LDFLAGS.
	* aclocal.m4: Regenerate.
	* configure: Regenerate.
	* Makefile.in: Regenerate.
	* testsuite/Makefile.in: Regenerate.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sol2-libgo-hwcaps.patch
Type: text/x-patch
Size: 916 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20161209/1aa0062a/attachment-0001.bin>
-------------- next part --------------

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University