[Bug preprocessor/60723] Line directives with incorrect system header flag

["nicholas.ormrod at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723

--- Comment #1 from Nicholas <nicholas.ormrod at hotmail dot com> ---
The preprocessor emits line directives with the system-header flag when using
complicated macros. This causes certain warnings, like -Wswitch and -Wreorder,
to be suppressed.

This report includes a patch as well as a detailed description.


== Reproduction Steps ==

Preprocessing must be done in a separate phase.

There must be a function-like macro which:

  (1) Is called with a newline inside of its arguments list
  (2) Is defined in a system header
  (3) Expands to contain a builtin macro followed by a non-builtin token


A minimal reproduction is attached. Compiling 'src.cpp' produces a div-by-zero
warning when compiled by "g++ -isystem. src.cpp". No warning is emitted when
preprocessing is split, such as with "g++ -isystem. -no-integrated-cpp
src.cpp".

== Cause ==

The preprocessed output of 'src.cpp' shows that a line directive is being
inserted after the __FILE__ macro, and that that directive is flagging
'src.cpp' as a system file (using the flag '3').

In a function-like macro expansion, regular tokens are line-marked as being
expanded at the opening parenthesis, while builtins are line-marked as being
expanded at the closing parenthesis (both of these choices are reasonable,
though the inconsistency is probably a design flaw). When a non-builtin follows
a builtin in a multiline macro call, the line numbers of the tokens are
inconsistent, forcing a line directive to be inserted.


== Details ==

This bug was occurring in our code base. We use ccache (which preprocesses
independently of main compilation) and gflags (which has sufficiently
complicated macros).

Testing was done on 4.9.

Git bisect blames 611f1003dbf4ebb341c2eda0fcc0e058c421eb6b (4.8.0 20120430),
authored by dodji on Mon Apr 30 11:43:43 2012 +0000. However, that diff does
not seem to be the root cause.

gcc -v

Using built-in specs.
COLLECT_GCC=./igpp
COLLECT_LTO_WRAPPER=/data/users/njormrod/src/gcc/_builds/39706bc97269366073d2eb4cf3ecf7872513627d/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../src/configure
--prefix=/data/users/njormrod/src/gcc/_builds/39706bc97269366073d2eb4cf3ecf7872513627d
--with-gmp=[local gmp-5.0.1] --with-mpfr=[local mpfr-3.0.0] --with-mpc=[local
mpc-0.8.2] --disable-multilib --enable-languages=c,c++ --disable-libgcj
--disable-bootstrap --disable-static
Thread model: posix
gcc version 4.9.0 20140331 (experimental) (GCC)