[Bug preprocessor/61817] New: Inconsistent location of tokens in the expansion list of a built-in macro

["dodji at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817

            Bug ID: 61817
           Summary: Inconsistent location of tokens in the expansion list
                    of a built-in macro
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dodji at gcc dot gnu.org

Consider this function-like macro definition in the inc.h file

------------------->inc.h<-------------------
#define F() const int line = __LINE__
------------------->8<-----------------------

Now consider its use in a file test.c:

------------------>cat -n test.c<----------------
     1  #include "inc.h"
     2
     3  void
     4  foo()
     5  {
     6    F
     7      (
     8       )
     9      ;
    10  }
------------------->8<---------------------

Running test.c through cc1 -quiet -E yields:

--------------------->8<--------------------
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "test.c"
# 1 "inc.h" 1
# 2 "test.c" 2

void
foo()
{
  const int line =

 8
    ;                                                                           
}
--------------------->8<----------------------

Note how tokens "const", "int", "line" and "=" are all on the same line as the
expansion point of the function-like F() macro, but how the token "8",
resulting from the expansion of the built-in macro __FILE__ is on the same line
as the closing parenthesis of the invocation of F().

This is the problem.  The result of the __FILE__ macro should be "6" and should
be on the same line (line 6) as the other tokens of the expansion-list of F().

This issue actually holds for the expansion of all built-in macros.


So more generelly, I would describe the issue as such:

When expanded in a function-like macro, the location of resulting tokens of a
built-in macro is set to the closing parenthesis of the enclosing function-like
macro invocation, rather than being set to the location of the expansion point
of the invocation the enclosing functin-like macro.