[Bug go/64021] New: Empty struct vs libffi

[Bug go/64021] New: Empty struct vs libffi

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

            Bug ID: 64021
           Summary: Empty struct vs libffi
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: rth at gcc dot gnu.org
                CC: cmang at google dot com

In go_struct_to_ffi, an empty struct is maped to ffi_type_void.

On i386, some ABIs return a struct pop 4 bytes of stack.  If one
calls a function returning a structure without preparing for this,
the stack will be corrupted.

On sparc32, functions returning a structure return to a different
address.  If one calls a function returning a structure without
preparing for this, the instruction after the call will be skipped.

In both cases, this causes reflect/all_test.go returnEmpty to fail.

I wonder what's better: follow C++ and map empty structures to a
single byte (i.e. no more zero-sized structures), or enhance libffi
to be able to deal with empty structures so that we don't have to
lie to libffi about the type being manipulated?

[Bug go/64021] Empty struct vs libffi

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

--- Comment #1 from Richard Henderson <rth at gcc dot gnu.org> ---
Oh, that should read "fail after the merge of the new libffi".

Current libffi happens to have nothing interesting in the stack
slot that's incorrectly popped, and to happens not to fail.  Not
so with the ffi_call_go rewrite.

[Bug go/64021] Empty struct vs libffi

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
FWIW, gcc and g++ pass empty struct differently on x86.

[Bug go/64021] Empty struct vs libffi

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-22
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug go/64021] Empty struct vs libffi

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #4 from Richard Henderson <rth at gcc dot gnu.org> ---
If we decide to follow C++, this is an abi change,
and thus should happen before gcc 5.  Thus P1.

[Bug go/64021] Empty struct vs libffi

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't that just because in C++ empty structs are forced by the FE into having
length of one byte?  I mean, if you:
struct S {};
int a = sizeof (struct S);
struct S b;
then in C it is int a = 0; and b is a common with zero size, while in C++ it is
int a = 1; and b has size 1.  So it is natural that those two (which are very
much different thing) are passed differently, I don't see anything to change on
that.  So, for go, the question is if it follows GNU C or C++ for empty
structs.

[Bug go/64021] Empty struct vs libffi

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

--- Comment #6 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Isn't that just because in C++ empty structs are forced by the FE into
> having length of one byte?

Yes, of course.

> I mean, if you:
> struct S {};
> int a = sizeof (struct S);
> struct S b;
> then in C it is int a = 0; and b is a common with zero size...

The zero-sized data thing is a rather useless GCC extension, IMO.
If you use -pedantic you will of course error out.

> So, for go, the question is if it follows GNU C or C++ for
> empty structs.

Since Go doesn't really have pointers in the usual sense, it's
difficult to ask the question "&a[1] != &a[2]".  Which *must* be
false for C++ and will be true for the GCC extension.

This does need a Go expert to figure out if there's another case
which can be determined from the language level.

[Bug go/64021] Empty struct vs libffi

[ian at airs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> ---
The Go language says that "Pointers to distinct zero-size variables may or may
not be equal" (http://golang.org/ref/spec#Comparison_operators).  So in the
language sense it would be OK to always convert zero-sized structs to contain a
single byte.  Go programmers routinely write things like make(chan struct{},
1000) and expect the channel to not take any space--the channel will keep a
count of elements but the element storage won't take any space; however, I
think that would continue to work as expected, since the libgo code looks at
the size in the Go type descriptor, which would continue to be zero.

I think the cleanest approach would be to modify libffi.  But as far as I can
always representing zero-sized structs as 1 byte in GIMPLE would work.  It
would mean we could remove Gcc_backend::non_zero_size_type.

I note that a zero-sized array is converted to an empty struct in go-ffi.c.  I
wonder how libffi handles that today.

[Bug go/64021] Empty struct vs libffi

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021

--- Comment #8 from Richard Henderson <rth at gcc dot gnu.org> ---
(In reply to Ian Lance Taylor from comment #7)
> I note that a zero-sized array is converted to an empty struct in go-ffi.c. 
> I wonder how libffi handles that today.

It doesn't.  There will be an assertion error.

I'll look at changing libffi to handle empty structures then.