This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building newlib for Cortex-M with LLVM


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]