Bug 67198 - [5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks compilation of existing programs
Summary: [5/6 Regression] change of type of syscall.RawSockaddr.Data on ppc64 breaks c...
Alias: None
Product: gcc
Classification: Unclassified
Component: go (show other bugs)
Version: 5.2.0
: P4 normal
Target Milestone: 5.3
Assignee: Ian Lance Taylor
Keywords: rejects-valid
Depends on:
Reported: 2015-08-12 23:44 UTC by Michael Hudson-Doyle
Modified: 2015-12-04 15:11 UTC (History)
3 users (show)

See Also:
Target: powerpc64le-linux-gnu
Known to work: 5.1.0
Known to fail: 5.2.0, 6.0
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
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:


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