gccgo, encoding/json: Marshal() not encoding struct correctly

[laboger]

The following problem occurs in the gcc5 branch and trunk. It was found when testing on pp64le Ubuntu 14.04 and 14.10 but the problem also occurs on x86 with gccgo. It works with golang on both platforms.

Here is a testcase that demonstrates the failure:

package main

import (
"encoding/json"
"fmt"
)

type HostConfig struct {
Memory int64
}

type Config struct {
Hostname string
}

type hostConfigWrapper struct {
InnerHostConfig *HostConfig
}

type ContainerConfigWrapper struct {
*Config
*hostConfigWrapper
}

func main() {

    conf := Config{
            Hostname:     "test1",
    }

    hostConf := HostConfig{
            Memory:          2048,
    }

    var hc hostConfigWrapper
    hc.InnerHostConfig = &hostConf
    var cf ContainerConfigWrapper
    cf.Config = &conf
    cf.hostConfigWrapper = &hc
    out1, _ := json.Marshal(cf)
    fmt.Println("marshalled data %v\n",string(out1))

}

Output should be:
marshalled data %v
{"Hostname":"test1","InnerHostConfig":{"Memory":2048}}

Output with gccgo:
marshalled data %v
{"Hostname":"test1"}

[mwhudson]

Is this the same problem as #7247 ?

[ianlancetaylor]

Yes, this is another aspect of #7247 .

[ianlancetaylor]

Closing as a duplicate.

[laboger]

I don't see why this is considered a duplicate.

The only place it fails is gccgo on both ppc64le and x86.

The testcase passes with golang on go 1.4.2 and 1.5. It is marked as a duplicate of an issue that fails on golang in both 1.4.2 and 1.5.

[ianlancetaylor]

I think it is a duplicate because I think that the reason that this problem occurs is the same reason that #7247 fails. If we fix #7247 in the gc toolchain, then encoding/json will start failing in the same way for gc. In other words, fixing #7247 in gc will force encoding/json to be fixed in such a way that this problem is fixed for gccgo.

[laboger]

Based on what I read in #7247 it doesn't sound like it will get fixed for some time (unplanned for go 1.5), and I'm not sure what that means in terms of getting it fixed in gccgo since it is still at 1.4.2.