PR preprocessor/64803 - __LINE__ inside macro is not constant

[This is a P1 regression for gcc 5]

Hello,

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() expand __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
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.

gcc/testsuite/ChangeLog:

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

Signed-off-by: Dodji Seketeli <dodji@redhat.com>
---
 gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c | 28 ++++++++++++++++++++++++++++
 libcpp/internal.h                          |  5 +++++
 libcpp/macro.c                             | 27 ++++++++++++++++++++++++---
 3 files changed, 57 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c

On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote:
> [This is a P1 regression for gcc 5]
> 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.

The thing that worries me a little bit on the patch is that
the new field is never cleared, only overwritten next time we attempt to
expand a function-like? toplevel macro.  So outside of that it can be stale,
point to a dead memory.  But if it is guaranteed it won't be accessed in
that case, perhaps that is safe.

	Jakub