使用#include "filename“时出现编译器错误

Question

我read说

#include filename导致将该指令替换为“分隔符”之间的指定序列标识的源文件的全部内容。

下面是一个简短的例子。使用g++ main.cpp f.h f.cpp编译会产生编译器错误。在我删除#include中的f.cpp后，程序将正确运行。我有两个问题。

1. 原始程序中错误的原因是什么？
2. #include filename真的将指令替换为引用文件的内容吗？

我问第二个问题，因为当我用int f(); (这是f.h的确切内容)替换有问题的行时，程序也正确地运行。

谢谢。

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;
}

使用原始程序运行g++ main.cpp f.h f.cpp的错误消息是

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.

更新：

我发现g++ main.cpp f.cpp f.h失败了，因为我的目录中有一个文件f.h.gch。程序正确编译后，我清理了那个.gch文件。

(很抱歉，我之前没有提供这方面的信息，因为我注意到了这一点。)

然而，g++ main.cpp f.cpp f.h生成f.h.gch。因此，如果我连续编译两次，这将是一个错误。

按照Donghui的建议，将f.h从g++中删除也是正确的。而且，它不生成f.h.gch文件。

我的问题很可能是 What is a .h.gch file?的翻版

Answer 1

在g++命令中，删除f.h。