Visual C++ Compiler Fatal Error C1001

Message Text

INTERNAL COMPILER ERROR
        (compiler file 'file', line number)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more information

Circumstances

Error C1001 is the main error in which the compiler admits to something having gone wrong internally, as opposed to being wrong with what its user provided as input or arranged as the execution environment. Moreoever, though what has gone wrong may have been anticipated, it is highly unexpected and not easily explained.

Broadly speaking, this error’s very many possible occurrences can be attributed to two processes: assertions and exceptions. For an assertion, the compiler anticipates something that may go wrong. For an exception, the compiler anticipates that something may go wrong.

Assertions

TO BE DONE

Exceptions

The value of this error when reporting an exception is greatly reduced because although the error message does at least cite which line of the user’s source code the compiler was grappling with at the time, the rest of the error message tells nothing of the faulting instruction or of the nature of the fault. What is described is not where the fault occurred but where in the compiler’s source code the compiler got round to reporting the fault as an internal compiler error. Indeed, all “exception” cases of error C1001 cite the same compiler file and one of just two line numbers, namely (in version 13.00.9466)

compiler file 'msc1.cpp', line 1414

and

compiler file 'msc1.cpp', line 2844

Of these, the second has much the greater opportunity for occurrence. It also may show as a different fatal error. Of particular significance is that if an error has already occurred, then an exception that would otherwise have caused this case of fatal error C1001 is instead reported as fatal error C1903.

Almost by definition, the C1001 cases that are caused by CPU exceptions are coding errors in the compiler. Perhaps this is just so obvious it needn’t be said, at least not directly. The product documentation manages little more than “the compiler cannot generate correct code for a construct”, which is true, but only in the best tradition of euphemism: it has absolutely no useful content, being trivially true of any error that stops compilation from proceeding to successful completion, and it is doubtful that anybody would think to write such a description except as euphemism. A frank explanation would admit to something such as “our programmers slipped up and the compiler has just tried to do some such rubbish as dereference a null pointer.”

It is arguable, of course, that details of the exception can have hardly any value even to the most advanced of users. The compiler’s code has caused a CPU exception and there is nothing the user can do about it except rewrite the code in the hope of avoiding the compiler’s defect. The exception details are better left to those of Microsoft’s own programmers who work on the compiler and know it well enough for deduction of what has gone wrong in their code.

That said, the exception details are obtainable, and without having to reproduce the exception while the compiler runs under a debugger. Instead, compile with the (undocumented) /Bd option to defeat the compiler’s exception handlers. The fault then passes from the compiler as unhandled, which in practice these days leaves it to be picked up by Dr Watson with an offer to send details to Microsoft over the Internet.

Among the known cases of the front-end C++ compiler raising error C1001 because a coding error causes a CPU exception are: