Re: Compiler options (optimization) and INTERNAL COMPILER ERROR

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 06/07/04 

Date: Mon, 07 Jun 2004 18:28:14 -0400

Carl Daniel [VC++ MVP] wrote:
> Victor Bazarov wrote:
>
>>Hello,
>>
>>While building some of our projects now with 7.1 we stumbled upon
>>an INTERNAL COMPILER ERROR happening in the _compiler_ while the
>>_linking_ is happening. The message we're getting looks like this:
>>----------------------------------------------------- begin message
>>[.. linker command, tons of files ..]
>>
>>Generating code
>>bla.bla..\g3triangle.c(364) : fatal error C1001: INTERNAL COMPILER
>> ERROR (compiler file
>>'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\x86\fppeeps.c', line 1368)
>> Please choose the Technical Support command on the Visual C++
>>
>>----------------------------------------------------- end message
>>I've never seen a compiler used during linking (and actually thought
>>that there is nothing left for it to do). Nonetheless, there it is,
>>crashing in front of our eyes.
>
>
> You must be compiling with /GL and linking with /LTCG. Th is causes the
> compiler back-end (c2.dll) to be invoked by the linker.

We kinda gathered that much.

>>A couple of questions. What could cause that? We tried using 'global
>>optimizations' and 'whole program optimizations', could that be it?
>>The file name it displays 'g3triangle.c' is actually pointing to a
>>file that doesn't exist any longer (the path has been renamed), could
>>that be the problem? And the main one, how do I fix the build
>>process? BTW, what's "the Technical Support command on the Visual
>>C++" and how to "choose" it?
>
>
> As always, the first thing to try is "rebuild all". It does sound like you
> have some cobwebs from a previous build since a non-existant file is being
> referenced.

Rebuild all is what we always do, just for the purpose of tying up our
CPUs and the network... Well, on a serious note, all our components are
fresh and rebuilding all doesn't help.

What else we've discovered is that if we use /Og and /GL in the same
command line for the compiler (/Og explicitly or implicitly through /Ox)
we get the crash. If we drop one of them (or both), no crash happens.

Cool, huh? Any idea as to what's going on there?

Anyway, we're dropping /GL switch. We can live without it, I guess.

Victor

Relevant Pages

  • Re: Protected classes within classes
    ... "Victor Bazarov" wrote in message ... > that even there you'll be encouraged to update your compiler... ...
    (comp.lang.cpp)
  • Re: VC++ 7.1 (.net 2003) compiler code optimization bug ?
    ... "Victor Bazarov" wrote: ... > Are you sure the problem is due to the compiler bug and not to the fact ... is zero which is it in the source file. ...
    (microsoft.public.vc.language)
  • Re: replacement for macro with # and ##
    ... > Victor Bazarov a écrit: ... >> done before the compiler gets to it. ... Templates are a way to make ... String literals have internal linkage, ...
    (comp.lang.cpp)
  • Re: Incomplete type as template argument
    ... "Victor Bazarov" wrote in message ... >> struct B ... >> Could someone please explain to me when the compiler actually does ... >> the template expansion, and is this method of using incomplete types ...
    (comp.lang.cpp)