https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68503
Bug ID: 68503
Summary: [powerpc64le] miscompilation of composite literal
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: michael.hudson at canonical dot com
CC: cmang at google dot com
Target Milestone: ---
Running commands like this on Ubuntu trusty ppc64le:
$ go get github.com/juju/juju/...
$ cd $GOPATH/src/github.com/juju/juju
$ git checkout 1.25
$ git apply << EOF
diff --git a/state/filesystem_test.go b/state/filesystem_test.go
index a7113bc..e0b20dd 100644
--- a/state/filesystem_test.go
+++ b/state/filesystem_test.go
@@ -258,7 +258,7 @@ func (s *FilesystemStateSuite) TestFilesystemInfo(c *gc.C)
{
// Explicitly set both MountPoint and ReadOnly to work around
// bug #1517611
- filesystemAttachmentInfo := state.FilesystemAttachmentInfo{MountPoint:
"/srv", ReadOnly: false}
+ filesystemAttachmentInfo := state.FilesystemAttachmentInfo{MountPoint:
"/srv"}
err = s.State.SetFilesystemAttachmentInfo(machineTag, filesystemTag,
filesystemAttachmentInfo)
c.Assert(err, jc.ErrorIsNil)
s.assertFilesystemAttachmentInfo(c, machineTag, filesystemTag,
filesystemAttachmentInfo)
EOF
$ go test -c -v ./state && ./state.test -gocheck.v -gocheck.f
TestFilesystemInfo
Leads to a failure along the lines of
... obtained state.FilesystemAttachmentInfo =
state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
... expected state.FilesystemAttachmentInfo =
state.FilesystemAttachmentInfo{MountPoint:"", ReadOnly:true}
What's going on appears to be that the line "filesystemAttachmentInfo :=
state.FilesystemAttachmentInfo{MountPoint: "/srv"}" is copying from the wrong
place in .rodata (the part that should be a pointer to string data is actually
the string data "action-9", which is part of a composite literal in a different
file).
This error appears to be present in the GIMPLE already.
The bug does not manifest on ppc64le with a newer gccgo or on arm64 at all, so
it's probably been fixed by now -- but it also disappears if I delete seemingly
irrelevant code, so it would be nice to know how this was fixed, and that it's
not just disappeared by luck. But only nice: we don't expect to use gccgo on
ppc64le for much longer.
