[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen: Work around Clang -E vs -Wunicode bug
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Fri, 24 Feb 2023 11:29:30 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=R39DJEougWpSxEFIPwBYJJ4S2mBajUEhWNIfe6fTpHc=; b=MrVmwkjs5sK+YkSe5kxAQaJKnr7I8y8AGn48TgHYNF56Y9DqFSP0jw/YZP5BQpD/dnTT8BIRAy6owribTsgDpTgRNDSs0UvlxwnlnBir+TbOb1X5vU3zYVBl3jy8YYR90qSifkKfG74ewYAjuzMfhvNlC5ZKpOuI2YxObvrdjSl8yZGW1wRxWbp/bXfHFaL6ozxOwLL6alDad6RHV0XJJXBOJ5wjcBGurYcK36Y/H+Hnt+ME3vblppwxoKqtQ8Ts1IFp0ymELFJ6Xf7oL+H8kUSd4qVfXIH0W45UX5/OQM65NhCS6qXoCC7skj1A9mp64JO6ILHV5z1sihnxNcGE/A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i6LvHK443hmK5Kl0Uisc8Jl6aSbk/4zsMUOYWzNgPCePhVQ6RxdoktFMpG/cUxBoB6hS9MftaJ8IVqGESK2s+1EnOZB5nhfXjGVHZ3td4sgSKD83kkW9x0Lu1KJXrtVfflJLUMQEsz9b3px+OSSc+5gxd3o9FLpr+I5Ix7kh/4VkX8nzvanYuoTjhuFoWAK8UIrSvEB1ZqfrgffjNLL6LuandJrWC4THwYSLQZGGwAqQ2VsTCJE64sCUGWxUAOJN/oNl8Wj4cZeRkQrrwTTYhJVFruo8H1msu4caVn7WKASzH0yiEbRZVoybdcXmwxrByTQ+dkuHyEtsAtpq6pdLXw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 24 Feb 2023 11:29:52 +0000
- Ironport-data: A9a23:N55IeKmbP5sXUZn96y+uTKro5gyjJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJOUTzSOfmMMTSnf9AgPYWx90kBuMPXydUxSAZo+Xo0RCMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE4p7auaVA8w5ARkPqgR5gOGzRH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 dAqBhY8d0jdvPOv3OufUMVpu8Q4NfC+aevzulk4pd3YJdAPZMmZBo/stZpf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVkVE3iea8WDbWUoXiqcF9t0CUv G/ZuU/+BQkXLoe3wjuZ6HO8wOTImEsXXapDRO3gqK873zV/wEQ6LxgdTQKdhsOcsRKuRI1vF hIf020x+P1aGEuDC4OVsweDiHyOswMYWtFQO/Yn8wzLwa3Riy6GAkAUQzgHb8Yp3OcmSDpv2 lKXktfBAT10rKbTWX+b7q2Trz65JW4SN2BqWMMfZQ4M4t2mqodjiBvKF4xnCPTs0IyzHizsy TeXqiR4n68UkcMAy6S8+xbAni6ooZ/KCAUy4207Q16Y0++wX6b9D6TA1LQRxa8owFqxJrVZg EU5pg==
- Ironport-hdrordr: A9a23:7EmMDKmAc4w3yGCdFCo+uWhHDUXpDfIH3DAbv31ZSRFFG/Fw9v re+cjzsCWf5Qr5N0tNpTntAsa9qArnhOdICOoqTNWftWvd2FdARbsKhbcKpQePJ8SUzJ8/6U 4PSclD4erLfDxHZJbBizVQy+xQu+VvKprY49s2Ek0dKj2Ct5sQlzuR1DzraHFLeA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 24/02/2023 11:17 am, Jan Beulich wrote:
> On 24.02.2023 11:50, Andrew Cooper wrote:
>> On 24/02/2023 7:27 am, Jan Beulich wrote:
>>> On 23.02.2023 23:03, Andrew Cooper wrote:
>>>> https://github.com/llvm/llvm-project/issues/60958
>>>>
>>>> While trying to work around a different Clang-IAS bug, I stubled onto
>>>>
>>>> In file included from arch/x86/asm-macros.c:3:
>>>> ./arch/x86/include/asm/spec_ctrl_asm.h:144:19: error: \u used with
>>>> no following hex digits; treating as '\' followed by identifier
>>>> [-Werror,-Wunicode]
>>>> .L\@_fill_rsb_loop\uniq:
>>>> ^
>>>>
>>>> It turns out that Clang -E is sensitive to the file extension of the source
>>>> file it is processing.
>>> I'm inclined to say there's no bug there in Clang. Gcc, while not affected
>>> in this specific regard, also treats .c and .S differently in some perhaps
>>> subtle ways.
>> This part was just an observation.
>>
>> Whether .c and .S should be treated the same or not, this -Wunicode
>> diagnostic is given against something which isn't in a char/string
>> literal, and that is a bug.
> Why are you thinking of only string literals? Gcc is quite okay with
>
> void test\u0024ä\u00F6ü(void) {}
>
> yielding "test$äöü" in the object file (I haven't understood yet why it
> dislikes \u0040, i.e. @.)
Oh - it seems universal-character-name is an explicitly permitted part
of identifier-nondigit.
In which case, Clang is arguably correct given a semantic expectation of
being a C file. I'll reword the commit message seen as I've not quite
pushed it yet.
~Andrew
|
