http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> 2012-01-31 18:27:32 UTC ---
> I've still to closer investigate why this happens. I suspect that this
> is also the cause of the IRIX failures (a libgo build is currently
> running). Maybe this is just and endianess problem: it's interesting
> that 32-bit Solaris/x86 works (little-endian), while 32-bit
> Solaris/SPARC and IRIX (both big-endian) don't.
I see now what's happening, and it's indeed an endianess problem:
In runtime/chan.c (__go_send_small), when sending an int (1) on a
big-endian system, the __builtin_memcpy copies the 4 low bytes from val
(0 in the case of val = 1) into b[], and runtime_chansend copies those
to the reciever. Similarly, in __go_receive_small even when a 4-byte
int had been received correctly, it would have been placed into the 4
low bytes of u.b by runtime_chanrecv, but the function returns all 8
bytes of u.v (0x10000 in this case).
This code cannot possibly work on a big-endian system, but I'm undecided
how to solve this in a clean way.
Rainer
