[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Wed Apr  6 18:35:16 2016
New Revision: 234794

URL: https://gcc.gnu.org/viewcvs?rev=234794=gcc=rev
Log:
PR preprocessor/61817
PR preprocessor/69391

  * internal.h (_cpp_builtin_macro_text): Update decl.
  * macro.c (_cpp_builtin_macro_text): Accept location for __LINE__.
  (builtin_macro): Accept a second location for __LINE__.
  (enter_macro_context): Compute both virtual and real expansion
  locations for the macro.

  * gcc.dg/pr61817-1.c: New test.
  * gcc.dg/pr61817-2.c: New test.
  * gcc.dg/pr69391-1.c: New test.
  * gcc.dg/pr69391-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61817-1.c
trunk/gcc/testsuite/gcc.dg/pr61817-2.c
trunk/gcc/testsuite/gcc.dg/pr69391-1.c
trunk/gcc/testsuite/gcc.dg/pr69391-2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/internal.h
trunk/libcpp/macro.c

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > This changed behavior with r213102 aka PR61861.
> 
> Perhaps this comment is relevant?
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861#c8


But the patch by Dodji is also wrong with rspect to this:

"I think the problem is that enter_macro_context() is passed the
location of the expansion point of the macro that is about to be
expanded.  But when that macro is built-in, builtin_macro() that is
then called by enter_macro_context() doesn't use the macro expansion
point location when expanding the __LINE__ builtin (in, e.g,
_cpp_builtin_macro_text) .  Rather, what it used is the location of
the closing parenthesis of the enclosing function-like macro
invocation or, more generally, the location of the previous token in
the stream."

according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61817#c3

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #3)
> This changed behavior with r213102 aka PR61861.

Perhaps this comment is relevant?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861#c8

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.4
Summary|Incorrect __LINE__  |[5/6 Regression] Incorrect
   |expansion with  |__LINE__ expansion with
   |-ftrack-macro-expansion=0   |-ftrack-macro-expansion=0
   |on g++5.2   |on g++5.2

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
This changed behavior with r213102 aka PR61861.
Self-contained testcase:
#define STR_I(X) #X
#define STR(X) STR_I(X)
#define LINE STR(__LINE__) STR(__LINE__)
#define LINE2() STR(__LINE__) STR(__LINE__)

int main()
{
  __builtin_printf ("%s\n", LINE);
  __builtin_printf ("%s\n", LINE2 ());
  return 0;
}

I'm getting the same behavior for function-like macros like other macros
though.