16,472
社区成员
发帖
与我相关
我的任务
分享VC6.0编译报错：fatal error C1001: INTERNAL COMPILER ERROR
最近接手了一个移植公司底层库的活儿。
底层库支持VC6.0 VS2008 等编译器版本
因为要向一个VC6.0的项目移植，所以第一步想，先用VC6.0编译这些要移植的底层库，生成相应的lib，然后在移植的项目中#include，#pragma comment(lib,)就完了
问题：卡在VC6.0编译底层库这块儿了
底层库在VC6.0 DEBUG WIN32模式下组建完美通过，然后转到Release WIN32就会出现如下问题
报错信息如下：
fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 1786)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
双击报错的信息，定位到了一处#include "..." （...是一个定义了一些结构体的头文件）
补充：
底层库放到VS2008中编译就没有这种问题。
想问问碰到过，或者研究过如上报错信息的大佬给支支招，帮忙分析分析这种错误出现的情况汇总，正好学习一下，挨个排查，大家多交流，多学习。
看网上一些帖子说是<iostream>和using namespace std;的问题
试了一下，没有任何作用，排除
底层库支持VC6.0 VS2008 等编译器版本
因为要向一个VC6.0的项目移植，所以第一步想，先用VC6.0编译这些要移植的底层库，生成相应的lib，然后在移植的项目中#include，#pragma comment(lib,)就完了
问题：卡在VC6.0编译底层库这块儿了
底层库在VC6.0 DEBUG WIN32模式下组建完美通过，然后转到Release WIN32就会出现如下问题
报错信息如下：
fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 1786)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
双击报错的信息，定位到了一处#include "..." （...是一个定义了一些结构体的头文件）
补充：
底层库放到VS2008中编译就没有这种问题。
想问问碰到过，或者研究过如上报错信息的大佬给支支招，帮忙分析分析这种错误出现的情况汇总，正好学习一下，挨个排查，大家多交流，多学习。
看网上一些帖子说是<iostream>和using namespace std;的问题
试了一下，没有任何作用，排除
...全文
请发表友善的回复…
发表回复
luj_1768 2019-09-10
- 打赏
- 举报
可能你的发行版编译功能是坏的。调试版编译是非商业应用，所以学习版和海盗版的软件常常能用，但是发行版编译需要正版的专业版或者企业版软件才能运行。
Mr_Effiya 2019-09-09
- 打赏
- 举报
自己一顿琢磨，终于找到问题所在了。
项目中#include递归包含的头文件太深了，导致路径太长，然后编译器就找不到正确的头文件了，这个不知道为什么在Release版里就不行
但是我直接#include "绝对路径"，问题解决了。
感谢各位对我的帮助，也学到了很多。
愉快结帖啦~~
Mr_Effiya 2019-09-09
- 打赏
- 举报
装的SP1没有装SP6，这个有影响吗，我装下试试
zgl7903 2019-09-07
- 打赏
- 举报
VC6 的ＳＰ６ 补丁安装了没？
如果不涉及保密的话，可以把工程打包发出来， 有人就可能帮到你
schlafenhamster 2019-09-07
- 打赏
- 举报
“Project”-》Setting-》C++->ProjectOptions 里 那些 “/" !
weixin_42177642 2019-09-07
- 打赏
- 举报
把Release的优化等级改成和debug的一样试试
Mr_Effiya 2019-09-06
- 打赏
- 举报
我觉得重点还是应该放在DEBUG模式编译没问题，但是Release编译有问题（没有太多的错误信息，就很头疼），根据楼上的提示，我想，我要在程序报错的地方（还好程序给了个出现错的位置）好好找找Debug和Release的问题了。
Mr_Effiya 2019-09-06
- 打赏
- 举报
谢谢老哥的回答（上次问题还多亏你~）
很可惜，项目的.dsp文件中没有找到msc1的任何信息
Mr_Effiya 2019-09-06
- 打赏
- 举报
这个是干什么的，VC6.0没有找到这个选项。
zgl7903 2019-09-06
- 打赏
- 举报
文本方式打开 .dsp, 删除找不到的文件 msc1.h msc1.cpp 的项， 然后打开项目重新编译， 当然先记得备份好
Mr_Effiya 2019-09-06
- 打赏
- 举报
谢谢的关注~
Release模式下的项目配置是 在静态库中使用MFC MT
我觉得可能跟项目设置没有太大关系，不过我会留意这点。
你所提到的#ifdef DEBUG预处理语句是指？
我的理解是由于这个预处理语句导致Release版本相关的库或者一些细节的地方与Debug中的不一样，导致了程序组建出现问题是吗。
schlafenhamster 2019-09-06
- 打赏
- 举报
编译器 选项: 输出 预处理· 到· 一个· 文件·
/P (Preprocess to a File)
/P (Preprocess to a File)
Mr_Effiya 2019-09-06
- 打赏
- 举报
我也在疑惑这个msc1.cpp
使用everything搜索了下整个电脑没有发现这个文件，或者是msc1.h，我也可以肯定这不是项目中所关联的文件
然后想会不会是项目代码中的哪行代码，又搜索了下整个项目，没有查找到
跟msc1.cpp相关的也就MSC_VER了
谢谢你的回复，我会关注这点的，我需要花些时间来想。
Eleven 2019-09-06
- 打赏
- 举报
比对一下Debug/Release两种模式下的工程配置，或者代码中#ifdef DEBUG预处理语句
schlafenhamster 2019-09-06
- 打赏
- 举报
"定位到了一处#include "..."" 有 什么 ？
'msc1.cpp' 是 什么 ？
'msc1.cpp' 是 什么 ？
schlafenhamster 2019-09-06
- 打赏
- 举报
Fatal Error C1001
INTERNAL COMPILER ERROR
(compiler file 'file', line number)
This error is most often generated in one of two cases:
Failure to recover the compiler's internal state following detection of a syntax error in the program. The first pass of the compiler will occasionally fail when attempting to recover its state following the detection of a malformed program. Typically, the compiler will have printed an error message (or messages) and will later produce an internal compiler error. In most cases, fixing the errors reported in your code and recompiling will solve the problem.
Failure of the code generator to find a way to generate correct code for a construct. This is most often caused by the interaction of an expression and an optimization option. The optimization has generated a tree which the compiler does not know how to handle. Such a problem can often be fixed by removing one or more optimization options when compiling the particular function containing the line indicated in the error message.
If no error messages have been emitted prior to the internal compiler error, then the next step is to determine which pass of the compiler is emitting the internal compiler error. This can be determined by recompiling the application with the /Bd option included. The /Bd option will cause each pass to print its name and arguments when it is invoked. The last pass invoked before the error is emitted is the one responsible.
If the pass indicated is P1, then the likely problem is still error recovery, as in number one above, but it is happening before the compiler has had a chance to emit the error message for the error it has just discovered. In such a case, examine the line on which the internal compiler error is reported. This line may also contain an unreported syntax error. Fixing any errors you find on that line will solve the internal compiler error in most cases. If you cannot find any error on that line or on the line previous to the one reported, contact Microsoft Product Support Services for help.
If the pass indicated is P2, then the problem can usually be fixed by removing one or more optimization options (or using a different code generator). You can determine which option is at fault by removing them one at a time and recompiling until the message goes away. Generally the last one removed is the problem and all other optimizations can be used safely. The most common culprits are /Og, /Oi, and /Oa. Once the offending optimization is discovered, it need not be turned off for the entire compilation. The offending optimization can be disabled with the optimize pragma while compiling the function where the error occurred, but enabled for the rest of the module.
More rarely, such errors occur at very low optimization levels or even when optimization is disabled. In such cases, rewriting the line where the error is reported (or possibly several lines including the one causing the error) may be a solution. If none of these options works, consult the technical support help file or the technical support section in one of your manuals.
INTERNAL COMPILER ERROR
(compiler file 'file', line number)
This error is most often generated in one of two cases:
Failure to recover the compiler's internal state following detection of a syntax error in the program. The first pass of the compiler will occasionally fail when attempting to recover its state following the detection of a malformed program. Typically, the compiler will have printed an error message (or messages) and will later produce an internal compiler error. In most cases, fixing the errors reported in your code and recompiling will solve the problem.
Failure of the code generator to find a way to generate correct code for a construct. This is most often caused by the interaction of an expression and an optimization option. The optimization has generated a tree which the compiler does not know how to handle. Such a problem can often be fixed by removing one or more optimization options when compiling the particular function containing the line indicated in the error message.
If no error messages have been emitted prior to the internal compiler error, then the next step is to determine which pass of the compiler is emitting the internal compiler error. This can be determined by recompiling the application with the /Bd option included. The /Bd option will cause each pass to print its name and arguments when it is invoked. The last pass invoked before the error is emitted is the one responsible.
If the pass indicated is P1, then the likely problem is still error recovery, as in number one above, but it is happening before the compiler has had a chance to emit the error message for the error it has just discovered. In such a case, examine the line on which the internal compiler error is reported. This line may also contain an unreported syntax error. Fixing any errors you find on that line will solve the internal compiler error in most cases. If you cannot find any error on that line or on the line previous to the one reported, contact Microsoft Product Support Services for help.
If the pass indicated is P2, then the problem can usually be fixed by removing one or more optimization options (or using a different code generator). You can determine which option is at fault by removing them one at a time and recompiling until the message goes away. Generally the last one removed is the problem and all other optimizations can be used safely. The most common culprits are /Og, /Oi, and /Oa. Once the offending optimization is discovered, it need not be turned off for the entire compilation. The offending optimization can be disabled with the optimize pragma while compiling the function where the error occurred, but enabled for the rest of the module.
More rarely, such errors occur at very low optimization levels or even when optimization is disabled. In such cases, rewriting the line where the error is reported (or possibly several lines including the one causing the error) may be a solution. If none of these options works, consult the technical support help file or the technical support section in one of your manuals.
