From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61563 invoked by alias); 12 Nov 2015 15:41:01 -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 61545 invoked by uid 89); 12 Nov 2015 15:41:01 -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 15:41:00 +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 135C649; Thu, 12 Nov 2015 07:40:46 -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 2F15C3F50D; Thu, 12 Nov 2015 07:40:58 -0800 (PST) Subject: Re: Building newlib for Cortex-M with LLVM To: Clemens Ladisch , Marcus Shawcroft , Olivier MARTIN References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644870C.6040106@ladisch.de> Cc: Newlib Mailing List From: Richard Earnshaw Message-ID: <5644B308.7030001@foss.arm.com> Date: Thu, 12 Nov 2015 15:50: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: <5644870C.6040106@ladisch.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00811.txt.bz2 On 12/11/15 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) > I looked at this with a colleague who had clang installed on his machine. It looks as though this problem may only occur when pre-processing assembly language files. If so, that's somewhat unfortunate. However, I'm not against taking a patch that's as trivial as this; it doesn't harm how GCC handles this file. It should however, be accompanied by a comment explaining that it's for compatibility with LLVM. R. > > Regards, > Clemens >