Building newlib for Cortex-M with LLVM
Thu Nov 12 14:22:00 GMT 2015
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 <email@example.com>
>>>> * 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
>>>> '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.
>> | 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 (184.108.40.206 6) shows such a space:
>> #define glue(a, b) a ## b
>> #define xglue(a, b) glue(a, b)
> 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.
More information about the Newlib