From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23879 invoked by alias); 11 Dec 2014 19:38:03 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 23790 invoked by uid 89); 11 Dec 2014 19:38:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 11 Dec 2014 19:38:02 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBBJbsHX023662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 11 Dec 2014 14:37:54 -0500 Received: from anchor.twiddle.net (vpn-224-205.phx2.redhat.com [10.3.224.205]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBBJbrk8003644; Thu, 11 Dec 2014 14:37:53 -0500 Message-ID: <5489F290.1080609@redhat.com> Date: Thu, 11 Dec 2014 19:38:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: libffi-discuss@sourceware.org, gcc-patches@gcc.gnu.org, gofrontend-dev@googlegroups.com, Andreas Krebbel Subject: Re: [PATCH 00/13] Go closures, libffi, and the static chain References: <1412973773-3942-1-git-send-email-rth@redhat.com> <20141211090623.GA30484@linux.vnet.ibm.com> In-Reply-To: <20141211090623.GA30484@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014/txt/msg00256.txt.bz2 On 12/11/2014 01:06 AM, Dominik Vogt wrote: > reflect.call > ../../../libgo/runtime/go-reflect-call.c:216 > reflect.call.N13_reflect.Value > GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/value.go:579 > reflect.Call.N13_reflect.Value > GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/value.go:412 > reflect_test.TestCallWithStruct > GCCDIR/build-go-closure/x86_64-unknown-linux-gnu/libgo/gotest30365/test/all_test.go:1490 > testing.tRunner > ../../../libgo/go/testing/testing.go:422 Indeed. libgo uses ffi_type_void to represent empty structures, and libffi would crash for x86_64 when passing such parameters. This does go back to an open bug report about how libffi handles empty structures in general. I've fixed this on the branch, and I'll push this through the proper channels later. r~