From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Olivier MARTIN <olivier@labapart.com>,
Clemens Ladisch <clemens@ladisch.de>
Cc: 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 14:22:00 -0000 [thread overview]
Message-ID: <5644983D.9010307@foss.arm.com> (raw)
In-Reply-To: <758ffcb7b7a715815f410b3b6bd1316e@labapart.com>
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.
next prev parent reply other threads:[~2015-11-12 13:46 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 [this message]
2015-11-12 15:33 ` Olivier MARTIN
2015-11-12 15:50 ` Richard Earnshaw
2015-11-12 15:56 ` Olivier MARTIN
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=5644983D.9010307@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=clemens@ladisch.de \
--cc=marcus.shawcroft@gmail.com \
--cc=newlib@sourceware.org \
--cc=olivier@labapart.com \
/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).