From patchwork Sun Sep 2 04:10:13 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: rbmj X-Patchwork-Id: 181157 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id B575A2C0090 for ; Sun, 2 Sep 2012 14:11:07 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1347163869; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-id:Date:From:User-Agent:MIME-version:To:Cc:Subject: References:In-reply-to:Content-type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=n7yrHdGHcbM/oTkR+iHx4dvdV+U=; b=WIwy135es+yElrZ o0G7YDTId0IQRyfemnbT3dx2EaGI87Bp0opISqiyGAphWrTQo2l/CZkb0xEBoV/X ngU7Qg5vj+9sGPkq7wT426pIo7aXkpDwJg+0aZV+EWXahAhJC8NVxHjO6gGttDZu 3jda/TWetujtxStUF7NY6h6VYZHY= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Message-id:Date:From:User-Agent:MIME-version:To:Cc:Subject:References:In-reply-to:Content-type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=kPAC+8RJ5r8fBH1bxc8EWpq2POEPvfQ5z3N9itXZFi7Mw3FiroKo22/5mO2EP7 glAsJC/xwI95u3tlCvnCqLsc2TQHT0+cXipUNxr1pGCtxPsGf09/Udv36KRVBw8j gZO6QLZwH+4iIwtFM5HTLZLCDGMJ8uCXQsyKP8Ft2WHDY=; Received: (qmail 8794 invoked by alias); 2 Sep 2012 04:10:55 -0000 Received: (qmail 8740 invoked by uid 22791); 2 Sep 2012 04:10:45 -0000 X-SWARE-Spam-Status: No, hits=1.7 required=5.0 tests=AWL, BAYES_00, BOTNET, KHOP_THREADED, RCVD_IN_DNSWL_NONE, RCVD_IN_HOSTKARMA_NO, RCVD_IN_HOSTKARMA_YE, RP_MATCHES_RCVD, TW_CX, TW_DC, TW_GC, TW_XL X-Spam-Check-By: sourceware.org Received: from vms173009pub.verizon.net (HELO vms173009pub.verizon.net) (206.46.173.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 02 Sep 2012 04:10:29 +0000 Received: from [10.16.147.104] ([unknown] [131.121.225.22]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M9P00MU6FL10E00@vms173009.mailsrvcs.net> for gcc-patches@gcc.gnu.org; Sat, 01 Sep 2012 23:10:16 -0500 (CDT) Message-id: <5042DC25.4060608@verizon.net> Date: Sun, 02 Sep 2012 00:10:13 -0400 From: rbmj User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-version: 1.0 To: Bruce Korb Cc: gcc-patches@gcc.gnu.org, bonzini@gnu.org, nathan@codesourcery.com Subject: Re: VxWorks Patches Back from the Dead! References: <503573B9.5090406@verizon.net> <50357EC8.3000709@gnu.org> <5037CD07.6020704@verizon.net> <5037DAA3.3080604@gnu.org> <5037E216.1040301@verizon.net> <50399984.1030405@verizon.net> <503F6AFD.4050005@verizon.net> In-reply-to: Content-type: multipart/mixed; boundary=------------030600000006020306030709 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi all, I have a new set of patches attached to this email. I've made a few changes since last time, and a full build works (finally, again). -The ioctl patch removes superfluous parens (thanks Paolo) -The mkdir patch has a more precise (or uglier, depending on your point of view :P) regex, and uses the variadic macro fix (thanks again Paolo) -It adds another fixincludes patch for vxworks *NOT GCC* regs.h as it doesn't include vxTypesOld.h, which it needs -The patch that adds the AC_ARG_ENABLE option to explicitly enable/disable libstdc++-v3 now has the argument changed from --disable-libstdc++-v3 to --disable-libstdcxx, as I was having weird issues and changing it seemed to work. If someone who has more experience with this than me (so anyone) knows that this should not make a difference than feel free to reject this change and I'll fall back to the old version. -The patch to allow machine_name to be skipped and enable fixincludes for vxworks is now *much* simpler (thanks Bruce) -There's a new patch to add NOMINMAX to libstdc++-v3/config/os/vxworks/os_defines.h to keep vxworks headers from defining min and max as macros. Note that the open() patch is NOT changed as the suggested change does not work when also compiling libstdc++-v3. Passing the third argument explicitly won't break anything - it will just be ignored - and is the only resolution that has worked so far. They're also not in the same order as I was rebasing quite a bit to try and keep history in sync. Also, I'm hoping since this is the third (or fourth for some of these patches) time submitting them, hopefully they can eventually make their way in :D. Could someone please volunteer to commit once it is all approved? Thank you all for the work you do on GCC, and the help you've given me to get my patches up to the standard! Robert Mason From f1132398e72e73c549cb7f608a3a43c0f4801bc3 Mon Sep 17 00:00:00 2001 From: rbmj Date: Mon, 4 Jun 2012 13:18:10 -0400 Subject: [PATCH 01/12] Added assert fixinclude hack for VxWorks. VxWorks's assert.h relies on adjacent string tokens being joined, and uses macros for some of the strings (e.g. __FILE__). However, it does not put a space after the end quote and before the macro, so instead of replacing the macro, gcc >= 4.7.x thinks it's a user-defined literal token, and since the lookup obviously fails, compilation of libstdc++ dies. This patch just replaces the assert.h header with another one that will work. It preserves the same format, just changes the spacing. Proposed by Robert Mason: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00385.html Approved by Nathan Sidwell: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00549.html Approved by Bruce Korb: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00552.html Changes: [fixincludes] inclhack.def (AAB_vxworks_assert): Added fix. fixincl.x: Regenerate --- fixincludes/inclhack.def | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def index 82792af..a9d582d 100644 --- a/fixincludes/inclhack.def +++ b/fixincludes/inclhack.def @@ -354,6 +354,46 @@ fix = { _EndOfHeader_; }; +/* + * Fix assert.h on VxWorks: + */ +fix = { + hackname = AAB_vxworks_assert; + files = assert.h; + mach = "*-*-vxworks*"; + + replace = <<- _EndOfHeader_ + #ifndef _ASSERT_H + #define _ASSERT_H + + #ifdef assert + #undef assert + #endif + + #if defined(__STDC__) || defined(__cplusplus) + extern void __assert (const char*); + #else + extern void __assert (); + #endif + + #ifdef NDEBUG + #define assert(ign) ((void)0) + #else + + #define ASSERT_STRINGIFY(str) ASSERT_STRINGIFY_HELPER(str) + #define ASSERT_STRINGIFY_HELPER(str) #str + + #define assert(test) ((void) \ + ((test) ? ((void)0) : \ + __assert("Assertion failed: " ASSERT_STRINGIFY(test) ", file " \ + __FILE__ ", line " ASSERT_STRINGIFY(__LINE__) "\n"))) + + #endif + + #endif + _EndOfHeader_; +}; + /* * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,