This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Building newlib for Cortex-M with LLVM
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Clemens Ladisch <clemens at ladisch dot de>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Olivier MARTIN <olivier at labapart dot com>
- Cc: Newlib Mailing List <newlib at sourceware dot org>
- Date: Thu, 12 Nov 2015 15:40:56 +0000
- Subject: Re: Building newlib for Cortex-M with LLVM
- Authentication-results: sourceware.org; auth=none
- References: <8473a04381ff7d35caa7ea1e8eb08772 at labapart dot com> <CAFqB+Pwg=bP5idYRTDTLtjxNfZMvuf3KeyPSMKLiJQ+Y3Nnsiw at mail dot gmail dot com> <5644870C dot 6040106 at ladisch dot de>
On 12/11/15 12:33, Clemens Ladisch wrote:
> Marcus Shawcroft wrote:
>> On 11 November 2015 at 23:16, Olivier MARTIN <olivier@labapart.com> 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
>