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: Olivier MARTIN <olivier at labapart dot com>, Clemens Ladisch <clemens at ladisch dot de>
- Cc: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Newlib Mailing List <newlib at sourceware dot org>
- Date: Thu, 12 Nov 2015 13:46:37 +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> <758ffcb7b7a715815f410b3b6bd1316e at labapart dot com>
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 <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)
>>
>>
>> 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.