Building newlib for Cortex-M with LLVM

[Olivier MARTIN]

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 <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
>> 

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