From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110545 invoked by alias); 12 Nov 2015 13:33:33 -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 110491 invoked by uid 89); 12 Nov 2015 13:33:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: 2.mo7.mail-out.ovh.net Received: from 2.mo7.mail-out.ovh.net (HELO 2.mo7.mail-out.ovh.net) (87.98.143.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Nov 2015 13:33:30 +0000 Received: from mail320.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 011C8FF8CA6 for ; Thu, 12 Nov 2015 14:33:26 +0100 (CET) Received: from RCM-86.6.27.10 (localhost [127.0.0.1]) by mail320.ha.ovh.net (Postfix) with ESMTPA id 20AF63A0063; Thu, 12 Nov 2015 14:33:23 +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 14:33:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 12 Nov 2015 13:46:00 -0000 From: Olivier MARTIN To: Clemens Ladisch Cc: Marcus Shawcroft , Newlib Mailing List , olivier@labapart.com Subject: Re: Building newlib for Cortex-M with LLVM In-Reply-To: <5644870C.6040106@ladisch.de> References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644870C.6040106@ladisch.de> Message-ID: <758ffcb7b7a715815f410b3b6bd1316e@labapart.com> X-Sender: olivier@labapart.com User-Agent: Roundcube Webmail/1.1.3 X-Webmail-UserID: olivier@labapart.com X-Ovh-Tracer-Id: 10747277562026487510 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrgeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-SW-Source: 2015/txt/msg00804.txt.bz2 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 -- Olivier MARTIN http://labapart.com - Lab A Part