Recent go changes broke alpha bootstrap

[Dominik Vogt]

On Thu, Oct 30, 2014 at 11:11:09AM +0100, Uros Bizjak wrote:
> On Thu, Oct 30, 2014 at 8:40 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> > Recent go changes broke alpha bootstrap:
> 
> > $files/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:22:29:
> > error: reference to undefined field or method ‘Mtim’
> >    modTime: timespecToTime(st.Mtim),
> >                              ^
> > /space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:60:50:
> > error: reference to undefined field or method ‘Atim’
> >   return timespecToTime(fi.Sys().(*syscall.Stat_t).Atim)

Hrm, this code relies on the old way of converting unions to Go
structures which, replaced the union with its first element
converted to a Go type.  I.e. the resulting size of the Go
representation of the union was wrong.

So, there was a kind hack that allowed to address the first field
of an anonymous union as if it was a plain field of the
surrounding structure (similar to C), and existing code now relies
on that.

I'm not quite sure about the best approach.  The attempt to
represent C unions in the "right" way is ultimately futile as Go
does not have the types necessary for it.  For example, the
handling of anonymous bit fields will never be right as it's
undefinied.  On the other hand I could fix the issue at hand by
changing the way anonymous unions are represented in Go.

Example:

  struct { int8_t x; union { int16_t y; int 32_t z; }; };

Was represented (before the patch) as

  struct { X byte; int16 Y; }

which had size 4, alignment 2 and y at offset 2 but should had
have size 8, alignment 4 and y at offset 4.  With the current
patch the Go layout is

  struct { X byte; artificial_name struct { y [2]byte; align [0]int32; } }

with the proper size, alignment and offset, but y is addressed as
".artificial_name.y" insted of just ".y", and y is a byte array
and not an int16.

I could remove the "artificial_name struct" and add padding before
and after y instead:

  struct { X byte; pad_0 [3]byte; Y int16; pad_1 [2]byte; align [0]int32; }

What do you think?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany