Enable gccgo based builds on Intel

[bpradipt]

The existing code doesn't compile with gccgo toolchain on Intel since the assembly code for sha256block and sha512block is specific to golang toolchain. The patch adds build constraints so that the code can be built with gccgo on multiple platforms including Intel and PowerPC.

Tested on the following environment
$go version
go version go1.4.2 gccgo (Ubuntu 5.1~rc1-0ubuntu1) 5.0.1 20150414 (prerelease) [gcc-5-branch revision 222102] linux/amd64

$ go version
go version go1.4.2 gccgo (GCC) 5.1.1 20150610 linux/ppc64le

Signed-off-by: Pradipta Kr. Banerjee bpradip@in.ibm.com

[stevvooe]

@bpradipt These files are unmodified from Go's standard library. We'll pick up changes from upstream when Go 1.5 is released, but we need to avoid forking.

How are these compiled for the stdlib when using gccgo?

[laboger]

The go stdlib is mirrored to the gcc source tree and then built into libgo as part of the gccgo build, with some minor modifications to allow them to build. The files that consist of plan9 assembler are not mirrored to the gcc source tree since gccgo does not know about plan9 assembler, but instead is built from a .go file.

I'm not sure what the original concern is here. Why are you rebuilding the source files in the crypto package when they are already being built as part of the golang toolchain and built into libgo when gccgo is built?

[stevvooe]

@laboger We are rebuilding them because we need access to the internal data structure. We avoid modifying them from the main Go distribution to avoid distributing a separate crypto implementation.

Typically, we only target pure Go from the gc toolchain. I'd argue the gccgo should push the changes required for an unmodified build upstream to the standard Go implementation.

Is there a specific application where you require this package for gccgo?