From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13974 invoked by alias); 26 Jul 2010 05:01:22 -0000 Received: (qmail 13521 invoked by uid 22791); 26 Jul 2010 05:01:20 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Jul 2010 05:01:13 +0000 Received: (qmail 10851 invoked from network); 26 Jul 2010 05:01:11 -0000 Received: from unknown (HELO ?211.74.234.20?) (cltang@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jul 2010 05:01:11 -0000 Message-ID: <4C4D168F.3080708@codesourcery.com> Date: Mon, 26 Jul 2010 05:01:00 -0000 From: Chung-Lin Tang User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Earnshaw CC: gcc-patches Subject: Re: [PATCH, ARM] soft/hard-float preprocessor symbol References: <4C471AF4.4000302@codesourcery.com> <1279921608.2191.14.camel@rwe-pc> In-Reply-To: <1279921608.2191.14.camel@rwe-pc> Content-Type: multipart/mixed; boundary="------------050700020506000500010806" X-IsSubscribed: yes 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: 2010-07/txt/msg02002.txt.bz2 This is a multi-part message in MIME format. --------------050700020506000500010806 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Content-length: 811 Richard Earnshaw wrote: > The tests should be on arm_pcs_default. If that has the value > ARM_PCS_AAPCS_VFP then __ARM_PCS_VFP should be defined. If it has the > value ARM_PCS_AAPCS, then __ARM_PCS should be defined. In other cases, > I think neither should be defined (leaving the option open to create new > pre-processor defines in future). > > That does leave nothing defined for the IWMMXT variant. I'm not > entirely sure what to do about that. It appears that this just follows > the base standard for calling, in which case __ARM_PCS probably should > be defined, but I want to think that case through further before making > that decision: there may be a subtlety that I've missed. > > R. Hi Richard, I have update the patch as you have suggested. Please see if this is okay. Thanks, Chung-Lin --------------050700020506000500010806 Content-Type: text/plain; name="pcs2.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="pcs2.diff" Content-length: 1737 SW5kZXg6IGFybS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGFybS5j CShyZXZpc2lvbiAxNjI1MjUpCisrKyBhcm0uYwkod29ya2luZyBjb3B5KQpA QCAtNzExLDcgKzcxMSw3IEBACiAgICB0aGUgbmV4dCBmdW5jdGlvbi4gICov CiBzdGF0aWMgaW50IGFmdGVyX2FybV9yZW9yZyA9IDA7CiAKLXN0YXRpYyBl bnVtIGFybV9wY3MgYXJtX3Bjc19kZWZhdWx0OworZW51bSBhcm1fcGNzIGFy bV9wY3NfZGVmYXVsdDsKIAogLyogRm9yIGFuIGV4cGxhbmF0aW9uIG9mIHRo ZXNlIHZhcmlhYmxlcywgc2VlIGZpbmFsX3ByZXNjYW5faW5zbiBiZWxvdy4g ICovCiBpbnQgYXJtX2NjZnNtX3N0YXRlOwpJbmRleDogYXJtLmgKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gYXJtLmgJKHJldmlzaW9uIDE2MjUyNSkK KysrIGFybS5oCSh3b3JraW5nIGNvcHkpCkBAIC05NCw3ICs5NCwxMyBAQAog CWlmIChhcm1fYXJjaF9pd21teHQpCQkJCVwKIAkgIGJ1aWx0aW5fZGVmaW5l ICgiX19JV01NWFRfXyIpOwkJXAogCWlmIChUQVJHRVRfQUFQQ1NfQkFTRUQp CQkJCVwKLQkgIGJ1aWx0aW5fZGVmaW5lICgiX19BUk1fRUFCSV9fIik7CQlc CisJICB7CQkJCQkJXAorCSAgICBpZiAoYXJtX3Bjc19kZWZhdWx0ID09IEFS TV9QQ1NfQUFQQ1NfVkZQKQlcCisJICAgICAgYnVpbHRpbl9kZWZpbmUgKCJf X0FSTV9QQ1NfVkZQIik7CQlcCisJICAgIGVsc2UgaWYgKGFybV9wY3NfZGVm YXVsdCA9PSBBUk1fUENTX0FBUENTKQlcCisJICAgICAgYnVpbHRpbl9kZWZp bmUgKCJfX0FSTV9QQ1MiKTsJCVwKKwkgICAgYnVpbHRpbl9kZWZpbmUgKCJf X0FSTV9FQUJJX18iKTsJCVwKKwkgIH0JCQkJCQlcCiAgICAgfSB3aGlsZSAo MCkKIAogLyogVGhlIHZhcmlvdXMgQVJNIGNvcmVzLiAgKi8KQEAgLTE2NDEs NiArMTY0Nyw5IEBACiAgIEFSTV9QQ1NfVU5LTk9XTgogfTsKIAorLyogRGVm YXVsdCBwcm9jZWR1cmUgY2FsbGluZyBzdGFuZGFyZCBvZiBjdXJyZW50IGNv bXBpbGF0aW9uIHVuaXQuICovCitleHRlcm4gZW51bSBhcm1fcGNzIGFybV9w Y3NfZGVmYXVsdDsKKwogLyogQSBDIHR5cGUgZm9yIGRlY2xhcmluZyBhIHZh cmlhYmxlIHRoYXQgaXMgdXNlZCBhcyB0aGUgZmlyc3QgYXJndW1lbnQgb2YK ICAgIGBGVU5DVElPTl9BUkcnIGFuZCBvdGhlciByZWxhdGVkIHZhbHVlcy4g ICovCiB0eXBlZGVmIHN0cnVjdAo= --------------050700020506000500010806--