Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

On 12.11.2015 13:46, Richard Earnshaw wrote:
> 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.

Your are correct Richard, I raised another clang defect 
https://llvm.org/bugs/show_bug.cgi?id=25508

--
Olivier
http://labapart.com - Lab A Part