From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122381 invoked by alias); 12 Nov 2015 15:16:10 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 122256 invoked by uid 89); 12 Nov 2015 15:16:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: 18.mo7.mail-out.ovh.net Received: from 18.mo7.mail-out.ovh.net (HELO 18.mo7.mail-out.ovh.net) (188.165.56.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Nov 2015 15:16:06 +0000 Received: from mail320.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id D053CFF8F00 for ; Thu, 12 Nov 2015 16:15:56 +0100 (CET) Received: from RCM-86.6.27.10 (localhost [127.0.0.1]) by mail320.ha.ovh.net (Postfix) with ESMTPA id BD6373A0063; Thu, 12 Nov 2015 16:15:53 +0100 (CET) Received: from cpc21-cmbg14-2-0-cust265.5-4.cable.virginm.net ([86.6.27.10]) by ssl0.ovh.net with HTTP (HTTP/1.1 POST); Thu, 12 Nov 2015 16:15:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 12 Nov 2015 15:33:00 -0000 From: Olivier MARTIN To: Richard Earnshaw Cc: Clemens Ladisch , Marcus Shawcroft , Newlib Mailing List Subject: Re: Building newlib for Cortex-M with LLVM In-Reply-To: <5644983D.9010307@foss.arm.com> References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644870C.6040106@ladisch.de> <758ffcb7b7a715815f410b3b6bd1316e@labapart.com> <5644983D.9010307@foss.arm.com> Message-ID: <55d0b247f4bb890cdd49a95fc86bf8d1@labapart.com> X-Sender: olivier@labapart.com User-Agent: Roundcube Webmail/1.1.3 X-Webmail-UserID: olivier@labapart.com X-Ovh-Tracer-Id: 12478348668495294170 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrgeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-SW-Source: 2015/txt/msg00809.txt.bz2 On 12.11.2015 13:46, Richard Earnshaw wrote: > On 12/11/15 13:33, Olivier MARTIN wrote: >> On 12.11.2015 12:33, Clemens Ladisch wrote: >>> Marcus Shawcroft wrote: >>>> On 11 November 2015 at 23:16, Olivier MARTIN >>>> wrote: >>>>> * The first one can be solved. The space in the call of CONCAT2(a, >>>>> b) by >>>>> CONCAT() is propagated into the subsequent calls. It means when the >>>>> strings >>>>> 'a' and 'b' are concatenated, the space is inserted between both >>>>> strings - >>>>> which is not the expected behaviour. >>>>> >>>>> The fix would be: >>>>> >>>>> -#define CONCAT(a, b) CONCAT2(a, b) >>>>> +#define CONCAT(a, b) CONCAT2(a,b) >>>> >>>> Have you looked at the C standard on this issue? I wonder which >>>> compiler, gcc or clang is not compliant with the standard. >>> >>> 6.10.3.3: >>> | If, in the replacement list of a function-like macro, a parameter >>> is >>> | immediately preceded or followed by a ## preprocessing token, the >>> | parameter is replaced by the corresponding argument’s preprocessing >>> | token sequence; […] >>> | each instance of a ## preprocessing token in the replacement list >>> | (not from an argument) is deleted and the preceding preprocessing >>> | token is concatenated with the following preprocessing token. >>> >>> Preprocessing tokens are defined in 6.4: >>> | preprocessing-token: >>> | header-name >>> | identifier >>> | pp-number >>> | character-constant >>> | string-literal >>> | punctuator >>> | each non-white-space character that cannot be one of the above >>> | […] >>> | White space may appear within a preprocessing token only as part of >>> | a header name or between the quotation characters in a character >>> | constant or string literal. >>> >>> So clang is wrong. >>> >>> It should be noted that example 4 (6.10.3.5 6) shows such a space: >>> >>> #define glue(a, b) a ## b >>> #define xglue(a, b) glue(a, b) >>> >>> >>> Regards, >>> Clemens >> >> Thanks Clemens for looking into the C standards. >> I did more investigation before raising a new Clang bug. And actually, >> the issue is more localized... >> It only happen when the concatenation macro is invoked into an >> assembly >> macro (ie: '.macro') - otherwise clang behaves as expected. >> Here is the clang issue: https://llvm.org/bugs/show_bug.cgi?id=25506 >> > > Not withstanding the clang macro-preprocessing issue, it looks as > though > clang is also incorrectly defining __USER_LABEL_PREFIX__. On an ELF > platform (such as ARM EABI) this should expand to nothing (there is no > prefix), and as such result from using CONCAT(a,b) should just be b. > > R. Your are correct Richard, I raised another clang defect https://llvm.org/bugs/show_bug.cgi?id=25508 -- Olivier http://labapart.com - Lab A Part