Preprocessor falls for a trick code during macro expansion


Bugzilla Link	PR26920
Status	NEW
Importance	P normal
Reported by	Vinicius Tinti (viniciustinti@gmail.com)
Reported on	2016-03-11 18:26:10 -0800
Last modified on	2016-03-12 10:53:48 -0800
Version	trunk
Hardware	PC Linux
CC	behanw@converseincode.com, hfinkel@anl.gov, jsmoeller@linuxfoundation.org, llvm-bugs@lists.llvm.org, rafael@espindo.la, rengolin@gmail.com, viniciustinti@gmail.com
Fixed by commit(s)
Attachments	`asm.S` (157 bytes, text/x-asm)
Blocks
Blocked by
See also	PR24494

Created attachment 16028
Preprocessor tricky code

The preprocessor is tricked to insert an extra space during macro expansion in
the following code:

// clang -E asm.S -o -
#define CONCAT(a,b) a##b
#define XMM(i)      CONCAT(%xmm, i)
.macro foo n
    x = XMM(\n)
.endm

Instead of emitting '%xmm\n' it emits '%xmm \n'.

Even weird if one define 'XMM(i)' as 'CONCAT(%xmm,i)' without a leading space
on 'i' it emits '%xmm\n'.

At least I dont expect such a change impact on codegen.

The line that triggers it is:

// https://github.com/llvm-mirror/clang/blob/master/lib/Lex/TokenLexer.cpp#L186
...
if (i != 0 && !Tokens[i-1].is(tok::hashhash) && CurTok.hasLeadingSpace())
  NextTokGetsSpace = true;
...

Quuxplusone / LLVMBugzillaTest

Preprocessor falls for a trick code during macro expansion #26919