From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42784 invoked by alias); 12 Nov 2015 13:46:43 -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 42774 invoked by uid 89); 12 Nov 2015 13:46:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Nov 2015 13:46:41 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 08D6849; Thu, 12 Nov 2015 05:46:27 -0800 (PST) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1E1F83F2E5; Thu, 12 Nov 2015 05:46:38 -0800 (PST) Subject: Re: Building newlib for Cortex-M with LLVM To: Olivier MARTIN , Clemens Ladisch References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644870C.6040106@ladisch.de> <758ffcb7b7a715815f410b3b6bd1316e@labapart.com> Cc: Marcus Shawcroft , Newlib Mailing List From: Richard Earnshaw X-Enigmail-Draft-Status: N1110 Message-ID: <5644983D.9010307@foss.arm.com> Date: Thu, 12 Nov 2015 14:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <758ffcb7b7a715815f410b3b6bd1316e@labapart.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00805.txt.bz2 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.