[Top] [All Lists]

Re: [PATCH 5/5] MIPS: LLVMLinux: Silence unicode warnings when preproces

To: Daniel Sanders <>
Subject: Re: [PATCH 5/5] MIPS: LLVMLinux: Silence unicode warnings when preprocessing assembly.
From: "Maciej W. Rozycki" <>
Date: Wed, 4 Feb 2015 10:36:24 +0000 (GMT)
Cc: Toma Tabacu <>, Ralf Baechle <>, Paul Burton <>, Paul Bolle <>, "Steven J. Hill" <>, Manuel Lauss <>, Jim Quinlan <>,,
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Alpine 2.11 (LFD 23 2013-08-11)
On Tue, 3 Feb 2015, Daniel Sanders wrote:

> From: Toma Tabacu <>
> Differentiate the 'u' GAS .macro argument from the '\u' C preprocessor unicode
> escape sequence by renaming it to '_u'.
> When the 'u' argument is evaluated, we end up writing '\u', which causes
> clang to emit -Wunicode warnings.
> This silences a couple of -Wunicode warnings reported by clang.
> The changed code can be preprocessed without warnings by both gcc and clang.

 I suspect it is a clang preprocessor bug that:

1. It interprets these character pairs as unicode escapes for assembly 
   sources, I think it should be up to the language translator rather 
   than the preprocessor, i.e. the assembler in this case (the notion of 
   unicode escapes for the preprocessor appears to be limited to 
   stringification, and then it is implementation-defined).

2. It considers these character pairs to be unicode escapes in the first 
   place given that they do not follow the syntax required for such 
   escapes, that is `\unnnn', where `n' are hex digits.

Of course it may be reasonable for us to work this bug around as we've 
been doing for years with GCC, but has the issue been reported back to 
clang maintainers?  What was their response?


<Prev in Thread] Current Thread [Next in Thread>