From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1825 invoked by alias); 22 Feb 2013 13:01:16 -0000 Received: (qmail 1817 invoked by uid 22791); 22 Feb 2013 13:01:16 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BF X-Spam-Check-By: sourceware.org Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Feb 2013 13:01:11 +0000 Received: by mail-wi0-f182.google.com with SMTP id hi18so686666wib.15 for ; Fri, 22 Feb 2013 05:01:09 -0800 (PST) X-Received: by 10.194.122.131 with SMTP id ls3mr3225621wjb.55.1361538069901; Fri, 22 Feb 2013 05:01:09 -0800 (PST) Received: from [192.168.2.99] (cpc3-cmbg8-0-0-cust629.5-4.cable.virginmedia.com. [82.6.102.118]) by mx.google.com with ESMTPS id t7sm3902935wiy.2.2013.02.22.05.01.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 05:01:08 -0800 (PST) Message-ID: <51276CA0.8030607@gmail.com> Date: Fri, 22 Feb 2013 13:01:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Anthony Green CC: libffi-discuss@sourceware.org, GCC Patches Subject: Re: [LIBFFI] Re: Re: [PATCH] Add support for PaX enable kernels (MPROTECT) References: <30737390.tlL1EbtGQR@laptop1.gw.ume.nu> <512673EA.40102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg01049.txt.bz2 On 21/02/2013 19:35, Anthony Green wrote: > On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote: >> Gcc-patches: Assuming AG approves, can we commit this without waiting for an >> upstream libffi release and doing a full merge? Currently GCC HEAD won't >> build libffi (and hence libjava) without it. > > This patch looks fine, thanks. I don't plan to merge back into GCC > for at least a week or two, so I think you should commit it to the GCC > tree independently. > > This means that 3.0.12 is broken for Cygwin. Are you able to produce > test results once you apply this change? I should probably issue a > quick 3.0.13 if the results are decent. Yes, the tests run fine (using libffi git HEAD from yesterday): > Native configuration is i686-pc-cygwin > > === libffi tests === > > > Running target unix > FAIL: libffi.call/closure_thiscall.c (test for excess errors) > WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable > > FAIL: libffi.call/closure_thiscall.c (test for excess errors) > WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable > > FAIL: libffi.call/closure_thiscall.c (test for excess errors) > WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable > > FAIL: libffi.call/closure_thiscall.c (test for excess errors) > WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable > > FAIL: libffi.call/closure_thiscall.c (test for excess errors) > WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable > > > === libffi Summary === > > # of expected passes 1924 > # of unexpected failures 5 I was using gcc-4.5.3, which is from before thiscall support was added, so those compile failures are unremarkable and expected. Given that, we have a clean sweep. cheers, DaveK