[Bug preprocessor/80071] New: __LINE__ is expanded incorrectly

["sxlijin+gcc at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.