4

While doing a bug report for CUDA's compiler, I ended up finding this strange behavior with gcc's preprocessing step. I currently use gcc 4.8.2.

Test file: test.cpp

#include <assert.h>

int main()
{
    int a = 1;
    assert (a >= 0);
    assert (a
            >= 0);
}

Command

gcc -E -x c++ -m64 -g -o "test.cpp4.ii" "test.cpp"

Result file: test.cpp4.ii

# 2 "test.cpp" 2

int main()
{
    int a = 1;
    ((a >= 0) ? static_cast<void> (0) : __assert_fail ("a >= 0", "test.cpp", 6, __PRETTY_FUNCTION__));
    ((a >= 0) ? static_cast<void> (0) : __assert_fail ("a >= 0",
 "test.cpp"
# 7 "test.cpp" 3 4
    ,
 8
# 7 "test.cpp" 3 4
    , __PRETTY_FUNCTION__))
                 ;

The multiline assert seems to be processed differently, leading to these # 7 "test.cpp" 3 4 lines. What does that mean exactly?

Update

Apparently, gcc 4.7 gives # 7 "test.cpp" (without the last 2 numbers).

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
BenC
  • 8,729
  • 3
  • 49
  • 68
  • 2
    Possible duplicate of [What is the meaning of lines starting with a hash sign and number like '# 1 "a.c"' in the gcc preprocessor output?](http://stackoverflow.com/questions/5370539/what-is-the-meaning-of-lines-starting-with-a-hash-sign-and-number-like-1-a-c) – Ciro Santilli OurBigBook.com Jan 17 '16 at 11:54

1 Answers1

5

It looks like line markers. As you might have noted, there's no trivial relation between line numbers in the original and preprocessed file. # 7 in the preprocessed input indicates that the source of next line was line7 in the original (which was named test.cpp).

3 4 are flags, meaning "macro expansion from system header" and extern "C"

GCC documentation

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • Further info: storing the original line number is useful for the compiler to generate error messages which indicate the line number from the original source – M.M Jun 01 '15 at 00:02
  • @MattMcNabb how much does ANSI say anything about it? I think it falls under the `# non-directive` syntax in C99, but then I could not find any semantics for that. Guessing it is just left undefined for implementations to extend at will like GCC did here? – Ciro Santilli OurBigBook.com Jun 01 '15 at 00:29
  • @CiroSantilli六四事件法轮功纳米比亚胡海峰 in ISO C whitespace is not significant between the `#` and the next token, and `# 7` would be an error; so this is a gcc extension (but that's fine because it only appears in intermediate output; extensions are allowed so long as conforming programs still compile properly) – M.M Jun 01 '15 at 00:33
  • @MattMcNabb why does the `# non-directive` syntax not apply here? N1256 6.10 Preprocessing directives. – Ciro Santilli OurBigBook.com Jun 01 '15 at 00:40
  • @CiroSantilli六四事件法轮功纳米比亚胡海峰 It does. *non-directive* is a grammar spec that's defined as *pp-tokens new-line*, so that is saying that a syntactically valid preprocessor line can start with `#` and end with newline, but `# #` would not be valid. – M.M Jun 01 '15 at 00:49
  • @CiroSantilli六四事件法轮功纳米比亚胡海峰: The contents of an `.ii` file are not defined by the standard, as this represents the communication between two phases of the compiler. The `# non-directive` syntax applies only to the _input_ of the first phase. – MSalters Jun 01 '15 at 09:07
  • @MSalters thanks for confirming it, that is what I had understood as well :-) – Ciro Santilli OurBigBook.com Jun 01 '15 at 09:20