https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80071
Bug ID: 80071
Summary: __LINE__ is expanded incorrectly
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sxlijin+gcc at gmail dot com
Target Milestone: ---
This is related to #20262, but is, I think, a much clearer example of how the
current implementation of __LINE__ is somewhat flawed.
$ cat -n bad_line_expansion.c
1 #include <stdio.h>
2
3 #define MACRO(statement) statement
4
5 int main() {
6 MACRO(
7 printf("%d\n", __LINE__);
8 printf("%d\n", __LINE__);
9 );
10 return 0;
11 }
$ gcc bad_line_expansion.c && ./a.out
9
9
$ clang bad_line_expansion.c && ./a.out
7
8
clang's behavior here is what I expect to see; the main reason I bring this up
is because this causes some rather violent errors when nesting gtest macros
(which use goto labels) because something like
EXPECT_NO_THROW({
EXPECT_THROW({ throw std::exception(); }, std::exception);
EXPECT_THROW({ throw std::exception(); }, std::exception);
});
can't actually compile, because gtest generates a goto for each EXPECT_THROW,
and uses __LINE__ to make them unique, but because the GCC preprocessor uses
the line number of the last line of the enclosing macro, the above ends up not
working.
N4606 (the closest to the C++11 spec) ยง16.8.1 [cpp.predefined] specifies that
__LINE__ should be expanded as "The presumed line number (within the current
source file) of the current source line (an integer literal)." It's hard for me
to see how the current "source line" should be considered 9 in this example.
