From: Olivier MARTIN <olivier@labapart.com>
To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
Cc: Clemens Ladisch <clemens@ladisch.de>,
Marcus Shawcroft <marcus.shawcroft@gmail.com>,
Newlib Mailing List <newlib@sourceware.org>
Subject: Re: Building newlib for Cortex-M with LLVM
Date: Thu, 12 Nov 2015 15:56:00 -0000 [thread overview]
Message-ID: <8bc4f3ab2787e4821e8f54d8daebc9ed@labapart.com> (raw)
In-Reply-To: <5644B308.7030001@foss.arm.com>
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
next prev parent reply other threads:[~2015-11-12 15:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 4:11 Olivier MARTIN
2015-11-12 11:17 ` Marcus Shawcroft
2015-11-12 12:39 ` Clemens Ladisch
2015-11-12 13:46 ` Olivier MARTIN
2015-11-12 14:22 ` Richard Earnshaw
2015-11-12 15:33 ` Olivier MARTIN
2015-11-12 15:50 ` Richard Earnshaw
2015-11-12 15:56 ` Olivier MARTIN [this message]
2015-11-12 15:59 ` Richard Earnshaw
2015-11-12 22:42 ` Jonathan Roelofs
2017-06-15 10:52 ` Emmanuel Blot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bc4f3ab2787e4821e8f54d8daebc9ed@labapart.com \
--to=olivier@labapart.com \
--cc=Richard.Earnshaw@foss.arm.com \
--cc=clemens@ladisch.de \
--cc=marcus.shawcroft@gmail.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).