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

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

[dodji at gcc dot gnu.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.

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

[dodji at gcc dot gnu.org]

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

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-07-16
           Assignee|unassigned at gcc dot gnu.org      |dodji at gcc dot gnu.org
     Ever confirmed|0                           |1

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

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
I sent a patch for this at
http://comments.gmane.org/gmane.comp.gcc.patches/316794

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

[dodji at gcc dot gnu.org]

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

Dodji Seketeli <dodji at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chengniansun at gmail dot com

--- Comment #2 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
*** Bug 61861 has been marked as a duplicate of this bug. ***

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

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The question of what value a __LINE__ macro should expand in the invocation of
a function-like macro that spans multiple lines was discussed by the C
committee in February 2015.  The consensus in the discussion was that:

1) the __LINE__ macro expands to the physical source line number (as opposed to
logical line number)
2) the logical line number is one greater than the number of new-line
characters read or introduced in translation phase 1 while processing the
source file to the current token
3) __LINE__ (along with all other) tokens only come into existence in phase 3
of translation
4) in an invocation of a function-like macro, any new-line characters must be
read to form the logical line containing the invocation (including its
arguments)

Thus, all __LINE__ tokens that are formed as a result of the expansion of a
function-like macro must expand to the number of the physical line that
contains the closing parenthesis the macro invocation.

According to this interpretation the following test is expected to pass (and
does with gcc 4.9 and 5):

#define F(x, y, z) a = __LINE__, b = x ## y, c = z

enum {
#line 10
    F
     (
      __LI,
      NE__,
      __LINE__
      )
};

#define A(e)  _Static_assert (e, #e)
    A (a == 15);
    A (b == 15);
    A (c == 15);

During the committee discussion it was observed that not all implementations
get this right.  A paper has been submitted into the Spring 2015 mailing to
reflect this issue (below).  The paper will be discussed at the April 2015
meeting in Lysaker.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1911.htm