[Bug c/64803] New: __LINE__ inside macro is not constant

[Bug c/64803] New: __LINE__ inside macro is not constant

[alserkli at inbox dot ru]

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

            Bug ID: 64803
           Summary: __LINE__ inside macro is not constant
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alserkli at inbox dot ru

The following code (simplified from
EXPECT_DEATH(VariantValue(VariantMatcher::SingleMatcher(varDecl())) in
llvm/tools/clang/unittests/ASTMatchers/Dynamic/VariantValueTest.cpp:149)

#define C(a, b) a ## b
#define L(x) C(L, x)
#define M(a) goto L(__LINE__); __LINE__; L(__LINE__):
M(a
  );

produces (gcc -E; 5.0.0 20150126)

 goto L5; 5; L4:

In gcc-4.7 the result was (after '#' lines removal)

 goto L5 ; 5 ; L5 :   ;

[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-26
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|__LINE__ inside macro is    |[5 Regression] __LINE__
                   |not constant                |inside macro is not
                   |                            |constant
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r213102 aka PR61861.

[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to affect quite a few packages, apparently gtest gained some popularity.

[Bug c/64803] [5 Regression] __LINE__ inside macro is not constant

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
Created attachment 34614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34614&action=edit
Candidate fix

This is the patch that I am currently testing.  It seems to fix the issue for
me.  Please let me know if it works for you.

[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, instead of doing such ugly hacks with __LINE__, IMHO gtest should use
__COUNTER__ instead, that doesn't care if it is on one line or multiple, and
doesn't get upset if you put more such macros on the same line.

[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant

[dodji at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #7 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
I have proposed the patch for review at
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02693.html

[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant

[dodji at gcc dot gnu.org]

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

--- Comment #8 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
Author: dodji
Date: Tue Feb  3 09:26:46 2015
New Revision: 220367

URL: https://gcc.gnu.org/viewcvs?rev=220367&root=gcc&view=rev
Log:
PR preprocessor/64803 - __LINE__ inside macro is not constant

Consider the example code mentionned in this PR:

 $ cat -n test.c
      1    #define C(a, b) a ## b
      2    #define L(x) C(L, x)
      3    #define M(a) goto L(__LINE__); __LINE__; L(__LINE__):
      4    M(a /* --> this is the line of the expansion point of M.  */
      5      ); /* --> this is the line of the end of the invocation of M.  */
 $

"cc1 -quiet -E test.c" yields:

 goto L5; 5; L4:
    ;

Notice how we have a 'L4' there, where it should be L5.  That is the issue.

My understanding is that during the *second* expansion of __LINE__
(the one between the two L(__LINE__)), builtin_macro() is called by
enter_macro_context() with the location of the expansion point of M
(which is at line 4).  Then _cpp_builtin_macro_text() expands __LINE__
into the line number of the location of the last token that has been
lexed, which is the location of the closing parenthesis of the
invocation of M, at line 5.  So that invocation of __LINE__ is
expanded into 5.

Now let's see why the last invocation of __LINE__ is expanded into 4.

In builtin_macro(), we have this code at some point:

   /* Set pfile->cur_token as required by _cpp_lex_direct.  */
   pfile->cur_token = _cpp_temp_token (pfile);
   cpp_token *token = _cpp_lex_direct (pfile);
   /* We should point to the expansion point of the builtin macro.  */
   token->src_loc = loc;

The first two statements insert a new token in the stream of lexed
token and pfile->cur_token[-1], is the "new" last token that has been
lexed.  But the location of pfile->cur_token[-1] is the same location
as the location of the "previous" pfile->cur_token[-1], by courtesy of
_cpp_temp_token().  So normally, in subsequent invocations of
builtin_macro(), the location of pfile->cur_token[-1] should always be
the location of the closing parenthesis of the invocation of M at line
5.  Except that that code in master now has the statement
"token->src_loc = loc;" on the next line.  That statement actually
sets the location of pfile->cur_token[-1] to 'loc'.  Which is the
location of the expansion point of M, which is on line 4.

So in the subsequent call to builtin_macro() (for the last expansion
of __LINE__ in L(__LINE__)), for _cpp_builtin_macro_text(),
pfile->cur_token[-1].src_loc is going to have a line number of 4.

I think the core issue here is that the location that is passed to
builtin_macro() from enter_macro_context() is not correct when we are
in presence of a top-most function-like macro invocation; in that
case, that location should be the location of the closing parenthesis
of the macro invocation.  Otherwise, if we are in presence of a a
top-most object-like macro invocation then the location passed down
to builtin_macro should be the location of the expansion point of the
macro.

That way, in the particular case of the input code above, the location
received by builtin_macro() will always have line number 5.

Boostrapped and tested on x86_64-unknown-linux-gnu against trunk.

libcpp/ChangeLog:

    * internal.h (cpp_reader::top_most_macro_node): New data member.
    * macro.c (enter_macro_context): Pass the location of the end of
    the top-most invocation of the function-like macro, or the
    location of the expansion point of the top-most object-like macro.
    (cpp_get_token_1): Store the top-most macro node in the new
    pfile->top_most_macro_node data member.
    (_cpp_pop_context): Clear the new cpp_reader::top_most_macro_node
    data member.

gcc/testsuite/ChangeLog:

    * gcc.dg/cpp/builtin-macro-1.c: New test case.

Signed-off-by: Dodji Seketeli <dodji@redhat.com>

Added:
    trunk/gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/internal.h
    trunk/libcpp/macro.c

[Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant

[dodji at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Dodji Seketeli <dodji at gcc dot gnu.org> ---
A fix for this issue was committed to trunk in revision r220367 and should be
available in GCC 5.  I am thus closing this problem report as FIXED.

Thank you for reporting this problem!