From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27379 invoked by alias); 3 Feb 2015 09:27:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 27209 invoked by uid 55); 3 Feb 2015 09:27:20 -0000 From: "dodji at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/64803] [5 Regression] __LINE__ inside macro is not constant Date: Tue, 03 Feb 2015 09:27:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dodji at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: dodji at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg00191.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803 --- Comment #8 from Dodji Seketeli --- 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 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