[llvm-bugs] [Bug 26920] New: Preprocessor falls for a trick code during macro expansion

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26920

            Bug ID: 26920
           Summary: Preprocessor falls for a trick code during macro
                    expansion
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: viniciustinti at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16028
  --> https://llvm.org/bugs/attachment.cgi?id=16028&action=edit
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;
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160312/222b9373/attachment.html>