mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Daniel Sanders <daniel.sanders@imgtec.com>
Cc: Toma Tabacu <toma.tabacu@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@imgtec.com>,
	Paul Bolle <pebolle@tiscali.nl>,
	"Steven J. Hill" <Steven.Hill@imgtec.com>,
	Manuel Lauss <manuel.lauss@gmail.com>,
	Jim Quinlan <jim2101024@gmail.com>,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] MIPS: LLVMLinux: Silence unicode warnings when preprocessing assembly.
Date: Wed, 4 Feb 2015 10:36:24 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1502041022150.22715@eddie.linux-mips.org> (raw)
In-Reply-To: <1422970639-7922-6-git-send-email-daniel.sanders@imgtec.com>

On Tue, 3 Feb 2015, Daniel Sanders wrote:

> From: Toma Tabacu <toma.tabacu@imgtec.com>
> 
> 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?

  Maciej

  reply	other threads:[~2015-02-04 10:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 13:37 [PATCH 0/5] MIPS: LLVMLinux: Patches to enable compilation of a working kernel for MIPS using Clang/LLVM Daniel Sanders
2015-02-03 13:37 ` [PATCH 1/5] LLVMLinux: Correct size_index table before replacing the bootstrap kmem_cache_node Daniel Sanders
2015-02-03 15:14   ` Christoph Lameter
2015-02-03 16:00     ` Daniel Sanders
2015-02-04 20:52       ` [PATCH v2 " Daniel Sanders
2015-02-04 21:06       ` [PATCH v3 1/5] slab: " Daniel Sanders
2015-02-05  8:37         ` Pekka Enberg
2015-02-04 19:33   ` [PATCH 1/5] LLVMLinux: " Pekka Enberg
2015-02-04 20:38     ` Daniel Sanders
2015-02-04 20:42       ` Pekka Enberg
2015-02-04 21:08         ` Daniel Sanders
2015-02-03 13:37 ` [PATCH 2/5] MIPS: LLVMLinux: Fix a 'cast to type not present in union' error Daniel Sanders
2015-02-03 13:37 ` [PATCH 3/5] MIPS: LLVMLinux: Fix an 'inline asm input/output type mismatch' error Daniel Sanders
2015-02-04 12:57   ` Maciej W. Rozycki
2015-02-05 15:43     ` Daniel Sanders
2015-02-06 10:09       ` Maciej W. Rozycki
2015-02-09 11:33   ` [PATCH v2 " Daniel Sanders
2015-02-09 14:12     ` Maciej W. Rozycki
2015-02-09 16:44     ` [PATCH v3 " Daniel Sanders
2015-02-03 13:37 ` [PATCH 4/5] MIPS: LLVMLinux: Silence variable self-assignment warnings Daniel Sanders
2015-02-03 13:37 ` [PATCH 5/5] MIPS: LLVMLinux: Silence unicode warnings when preprocessing assembly Daniel Sanders
2015-02-04 10:36   ` Maciej W. Rozycki [this message]
2015-02-05 10:25     ` Toma Tabacu
2015-02-05 12:35       ` Maciej W. Rozycki
2015-02-05 12:56         ` Måns Rullgård
2015-02-11 17:37           ` Daniel Sanders

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=alpine.LFD.2.11.1502041022150.22715@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=Steven.Hill@imgtec.com \
    --cc=daniel.sanders@imgtec.com \
    --cc=jim2101024@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@gmail.com \
    --cc=paul.burton@imgtec.com \
    --cc=pebolle@tiscali.nl \
    --cc=ralf@linux-mips.org \
    --cc=toma.tabacu@imgtec.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

all inboxes | Powered by JetHome®