0

I read that

#include filename causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters.

A short example is below. Compiling with g++ main.cpp f.h f.cpp gives compiler error. The program runs correctly after I remove the #include in f.cpp. I have two questions.

  1. What is the cause of error in the original program?

  2. Does #include filename really just replace the directive with the content of the quoted file?

I ask the second question because the program also runs correctly when I replace the problematic line with int f(); (which is the exact content of f.h).

Thank you.

f.h

int f();

f.cpp

#include "f.h" // problem
int f() { return 1; }

main.cpp

#include <iostream>
#include "f.h"
int main() {
    std::cout << f() << std::endl;
}

The error message of running g++ main.cpp f.h f.cpp with original program is 

f.cpp: In function 'int f()':
f.cpp:2:5: internal compiler error: in ggc_record_overhead, at ggc-common.c:1013
 int f() { return 1; }
     ^
0x8ae8eb ggc_record_overhead(unsigned long, unsigned long, void*, char const*, int, char const*)
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/ggc-common.c:1013
0xc4af71 ggc_internal_alloc_stat(unsigned long, char const*, int, char const*)
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/ggc-page.c:1317
0xa48462 get_combined_adhoc_loc(line_maps*, unsigned int, void*)
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/libcpp/line-map.c:136
0xa9a5ff gimple_set_block(gimple_statement_base*, tree_node*) [clone .isra.8]
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple.h:1489
0xa9a5ff lower_stmt
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple-low.c:239
0xa9a5ff lower_sequence
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple-low.c:206
0xa9b481 lower_gimple_bind
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple-low.c:415
0xa9b5c6 lower_function_body
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple-low.c:118
0xa9b5c6 (anonymous namespace)::pass_lower_cf::execute() [clone .lto_priv.4979]
        /apps2/tools/gcc/4.9.2/gcc-4.9.2-src/gcc/gimple-low.c:184
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

UPDATE:

I found that g++ main.cpp f.cpp f.h fails because there is a file f.h.gch in my directory. The program compiles correctly after I cleanup that .gch file.

(I'm sorry that I did not provide this information before as I just noticed it.)

However, g++ main.cpp f.cpp f.h generates f.h.gch. So if I compile twice consecutively, it'll be an error.

Following Donghui's advice, removing f.h from g++ also compiles correctly. And, it does NOT generate the f.h.gch file.

My question is likely a duplicate of What is a .h.gch file?

Community
  • 1
  • 1
kgf3JfUtW
  • 13,702
  • 10
  • 57
  • 80
  • Yes, #include filename replaces the directive with the content of the quoted file. The code you've shown should work. Something else (that you didn't show) caused the "problem". Tell us more. In particular, how did you compile? What was the error message? – Donghui Zhang Oct 21 '16 at 19:11
  • 1
    "What is the cause of error in the original program? " What does the error message tell you? – juanchopanza Oct 21 '16 at 19:13
  • @DonghuiZhang Thank you. I have now included the error message. It says "internal compiler error", which I don't quite understand. – kgf3JfUtW Oct 21 '16 at 19:17
  • @juanchopanza I have now included the error message, thanks. – kgf3JfUtW Oct 21 '16 at 19:24
  • "Internal compiler error" is always a compiler bug. You might be able to work around it, but it's still the compiler's fault. – Pete Becker Oct 21 '16 at 19:35
  • @PeteBecker Thank you. As in my update, the compiler error was caused by a `.gch` file in my directory. I have now marked the question as a duplicate. – kgf3JfUtW Oct 21 '16 at 19:44

1 Answers1

1

In your g++ command, remove f.h.

Donghui Zhang
  • 1,133
  • 6
  • 8
  • That might work around the compiler bug, but there's nothing inherently wrong with the code and the command line as written. Yes, compiling a header is usually a mistake, but there's nothing illegal there. – Pete Becker Oct 21 '16 at 19:37
  • 1
    @Donghui Thank you for the response. As in my update, the compiler error was caused by a `.gch` file in my directory. I have now marked the question as a duplicate. – kgf3JfUtW Oct 21 '16 at 19:45