From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13297 invoked by alias); 2 Aug 2014 17:32:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13287 invoked by uid 89); 2 Aug 2014 17:32:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 02 Aug 2014 17:32:28 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 388AB3401C3; Sat, 2 Aug 2014 17:32:26 +0000 (UTC) From: Mike Frysinger To: gdb-patches@sourceware.org Cc: Pedro Alves , Masaki Muranaka Subject: Re: [PATCH][sim] Fix linkage errors in Clang. Date: Sat, 02 Aug 2014 17:32:00 -0000 Message-ID: <2209489.Y8eKTZuHJx@vapier> User-Agent: KMail/4.13.1 (Linux/3.14.2; KDE/4.13.1; x86_64; ; ) In-Reply-To: <538866FD.4020805@redhat.com> References: <538866FD.4020805@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6352322.Fsn6nMrqKv"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00031.txt.bz2 --nextPart6352322.Fsn6nMrqKv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Content-length: 665 On Fri 30 May 2014 12:09:49 Pedro Alves wrote: > On 05/14/2014 03:31 AM, Masaki Muranaka wrote: > > By differences about inline function, we can't build simulators on Clan= g. >=20 > The difference is probably that Clang defaults to C99. > You should probably be using CC=3D"clang -std=3Dgnu89". >=20 > Patchwise, please try using __attribute__ ((gnu_inline)). yeah i'm not a fan of sprinkling __clang__ everywhere. i'm aware that ther= e's=20 a bunch of __GNUC__ in there, but those should get cleaned up/centralized=20 rather than expanded. a quick glance shows that there's already cases wher= e=20 that can happen (like moving to ATTRIBUTE_NORETURN). -mike= --nextPart6352322.Fsn6nMrqKv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT3SCsAAoJEEFjO5/oN/WB55AP/jJWV9FjHuFrhOvoUy+BvLUx 69uPR8xIkmzVk/DFDKQN11i2DpP8fRaqAhQCQeii8NOwJhQroz/l8jy114HVATqt ll2VVk0vofLWU3Tfl/GOtHdw4IYKJuyMFEV0RFTSPNVukdZkA/6yZoUN7pcrT/gS k8Z1/wgCipF2pkLiARp70PjLnWFz9PF5R11Gj7F4IlSUr3V/2DU232ewtMsHd9vU 5xWLVJ7nFULryhIjCKkZs3R4vCgikXQY/QUCVWnTYfeBMZjyzaoLuFPNSwBCeFDf IEevbdjMFZ9+vpnBz3EyeOudQ8UVt7cnCG0WtWqejrs73tQCLqjspFVZgxG7sShZ n0Q/cY+zdRjsDYh+e0bVuBLdehtZzOTCm7OIAusU7iNl/+jQBXWV/WSGoKgycHqc 0wcl9NlQ504Cx1xNF61AUyOkqGl8dgGNIBf+ji6J/stHfaknwddqcaqf63TCnBIi 6W+IKVx1CBnrLYutb5Avacvbt482mpYG98goW5sRn3vs2xq4tafuHRwt9AFi/fNg 2iwAsQutaDczLjRyrCLnmdcma7fQ85WFAGEkuYsI0qoYamGGc/OLO9HXiBfUoBZS IPdd/+dA4FnUPVBfSPOUCRVvy11acKpvLEV9z11LNMKrW+q9Pt9qmGfwDz94t+K1 E1l2O9UFS6h6EeW572PK =HMZM -----END PGP SIGNATURE----- --nextPart6352322.Fsn6nMrqKv--