Bug 67198

Summary:	[5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs
Product:	gcc	Reporter:	Michael Hudson-Doyle <michael.hudson>
Component:	go	Assignee:	Ian Lance Taylor <ian>
Status:	RESOLVED FIXED
Severity:	normal	CC:	boger, doko, doko
Priority:	P4	Keywords:	rejects-valid
Version:	5.2.0
Target Milestone:	5.3
Host:		Target:	powerpc64le-linux-gnu
Build:		Known to work:	5.1.0
Known to fail:	5.2.0, 6.0	Last reconfirmed:

Description Michael Hudson-Doyle 2015-08-12 23:44:17 UTC

https://github.com/golang/go/issues/11469 / https://go.googlesource.com/gofrontend/+/a850225433a66a58613c22185c3b09626f5545eb%5E!/ fixed gccgo tip to match what Go 1.5 does for the type of syscall.RawSockaddr.Data on ppc64le, which sounds good, but it means that the type is different from previous releases of gccgo on ppc64le, which means that programs that used to compile now don't, including docker:

https://launchpadlibrarian.net/214319094/buildlog_ubuntu-wily-ppc64el.docker.io_1.6.2~dfsg1-1ubuntu4_BUILDING.txt.gz

I don't know that docker can be changed in a way that will build with both new and old gccgo, which seems pretty unfortunate. At least changing the Go 1.5 type would allow that, but it's way too late for that.

Comment 1 Ian Lance Taylor 2015-08-13 00:38:57 UTC

I can't win.

I deeply do not care about this type.  Please sort it out with Lynn Boger.  Thanks.

Comment 2 boger 2015-08-13 13:10:59 UTC

I was asked to make this fix to gccgo.  A corresponding Docker fix is needed which is described here https://github.com/docker/libcontainer/pull/625.

It is unfortunate it introduces an incompatibility which means that new Docker source can't be built with older gccgo compilers, but this is a bug and could lead to incorrect execution.  It is assuming the field is signed when it should be treated as unsigned.

Comment 3 Ian Lance Taylor 2015-08-13 13:46:06 UTC

I don't think there is any risk of incorrect execution here.  Nothing is going to care whether these bytes are signed or not.

Comment 4 boger 2015-08-13 14:53:45 UTC

I'll admit I'm not familiar with how this field could ever be used.

But you are saying that no code will ever try to do a compare with this field when has a value greater than 127?  If it did then it would get the wrong result because of the sign.

In my opinion it is better to fix it now instead of wait until someone potentially hits a problem with it, when it will cost a lot more to investigate and fix.  Especially since go 1.5 in golang is correct.

Yesterday I got another (unrelated) question about the granularity of gccgo build tags.  Seems like a more precise gccgo build tag would help here.

Comment 5 Ian Lance Taylor 2015-08-13 15:46:36 UTC

I am indeed saying that no code is ever going to do a less-than or greater-than comparison with the bytes in an IP address.

Not that that has much to do with what we should do here.  I'm just saying that the possibility of code that behaves incorrectly because these bytes are signed or unsigned is not an issue.  It won't happen and we should not worry about it.

What matters is whether programs compile or not.

Comment 6 boger 2015-08-14 12:28:45 UTC

I am working with our Docker team to provide a source change that will compile with old and new gccgo.

Comment 7 Richard Biener 2015-12-04 10:45:59 UTC

GCC 5.3 is being released, adjusting target milestone.

Comment 8 boger 2015-12-04 13:37:43 UTC

This fix is already in the gcc 5 branch commit r226595.

It was tracked in the golang issues database https://github.com/golang/go/issues/11469.

Comment 9 Ian Lance Taylor 2015-12-04 15:11:53 UTC

Closing.