Re: Building newlib for Cortex-M with LLVM

[Olivier MARTIN <olivier@labapart.com>]

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

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