From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107320 invoked by alias); 12 Nov 2015 15:50:28 -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 107308 invoked by uid 89); 12 Nov 2015 15:50:27 -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:50:26 +0000 Received: from mail320.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 7C5C8FF8E89 for ; Thu, 12 Nov 2015 16:50:14 +0100 (CET) Received: from RCM-86.6.27.10 (localhost [127.0.0.1]) by mail320.ha.ovh.net (Postfix) with ESMTPA id 627263A0063; Thu, 12 Nov 2015 16:50:11 +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:50:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 12 Nov 2015 15:56: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: <5644B308.7030001@foss.arm.com> References: <8473a04381ff7d35caa7ea1e8eb08772@labapart.com> <5644870C.6040106@ladisch.de> <5644B308.7030001@foss.arm.com> Message-ID: <8bc4f3ab2787e4821e8f54d8daebc9ed@labapart.com> X-Sender: olivier@labapart.com User-Agent: Roundcube Webmail/1.1.3 X-Webmail-UserID: olivier@labapart.com X-Ovh-Tracer-Id: 13057624171298713306 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrgeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-SW-Source: 2015/txt/msg00812.txt.bz2 On 12.11.2015 15:40, Richard Earnshaw wrote: > 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 >> Yes, it is what I also noticed when I raised the clang issue earlier today: https://llvm.org/bugs/show_bug.cgi?id=25506 I am not sure it is worth to push a workaround in Newlib as this other issue I found 'Inline assembly does not support macro' https://llvm.org/bugs/show_bug.cgi?id=25495 is blocking. -- Olivier http://labapart.com - Lab A Part