fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c' , line 148)

[PufferFish]

Hi folks,

I hope that this is the correct group for these things, apologies if not.

I've got a strange compiler error. It appears to be similar to the issue
described in knowledgebase article 320004 except that particular problem was
fixed in .NET 2003, according to the article.

The error I get is:

fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c' , line 148)

Please choose the Technical Support command on the Visual C++

Help menu, or open the Technical Support help file for more information

If I follow the steps outlined in 320004, #pragma optimize("g", off) and on
around the affected function the problem stops. The error does not show in
debug builds, so this appears to be an optimisation error. Also in common
with 320004, there is a while loop involved. I've tried rearranging the code
a bit with no luck, and various optimisation changes didn't fix it (bar
switching 'em all off).

I've done various searches and found compiler errors that refer to line 146
(mostly .NET 2002) of main.c and a bunch referring to 148, some of which are
related to throw/catch (which is not the case here).
This code compiled and ran OK under VC6 (SP5). We're currently evaluating
our MSDN version of .NET2003 with compiles under both versions to check that
everything still works OK under the new compiler before doing a full
upgrade. With the #pragmas around the code, the code still compiles OK under
both versions but I was curious as to whether there is a fix available for
this problem or if there are any more details?

Cheers,

PufferFish.

[benben]

You may supply the problematic line 148 and its context so that we can
actually know what is going on. It also appears that you may have selected
incorrect optimization options. Why don't you also supply the command line
you used to compile the code.

ben

Hi folks,

I hope that this is the correct group for these things, apologies if not.

I've got a strange compiler error. It appears to be similar to the issue
described in knowledgebase article 320004 except that particular problem was fixed in .NET 2003, according to the article.

The error I get is:

fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c' , line 148)

Please choose the Technical Support command on the Visual C++

Help menu, or open the Technical Support help file for more information

If I follow the steps outlined in 320004, #pragma optimize("g", off) and on around the affected function the problem stops. The error does not show in
debug builds, so this appears to be an optimisation error. Also in common
with 320004, there is a while loop involved. I've tried rearranging the code a bit with no luck, and various optimisation changes didn't fix it (bar
switching 'em all off).

I've done various searches and found compiler errors that refer to line 146 (mostly .NET 2002) of main.c and a bunch referring to 148, some of which are related to throw/catch (which is not the case here).
This code compiled and ran OK under VC6 (SP5). We're currently evaluating
our MSDN version of .NET2003 with compiles under both versions to check that everything still works OK under the new compiler before doing a full
upgrade. With the #pragmas around the code, the code still compiles OK under both versions but I was curious as to whether there is a fix available for
this problem or if there are any more details?

Cheers,

PufferFish.

[PufferFish]

"benben" <be******@yahoo.com.au> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

You may supply the problematic line 148 and its context so that we can
actually know what is going on. It also appears that you may have selected
incorrect optimization options. Why don't you also supply the command line
you used to compile the code.

Hi,

Many thanks for your response. The "line 148" isn't in my code; I don't have
an F drive. It refers to Microsoft's source base for Visual C; so the main.c
and the error is connected with that. If you paste the actual error string
into google, you'll see what I mean.

The line of actual code that bails this is:

if ( (ERT_INFO == type) && (op_flags[EHFL_SUPRESSINFO]) )
return (false);

.... which is clearly mighty harmless. So something else somewhere else is
setting this up to happen. I've not been able to distill it into a separate
code-base that specifically causes the error to occur.

The compilation command line is:

/O2 /D "NDEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /FD /EHsc /MT /J
/YX"stdafx.h" /Fp".\Release/cerrtest.pch" /Fo".\Release/" /Fd".\Release/"
/FR".\Release/" /W3 /nologo /c /Zi

PufferFish.

[Carl Daniel [VC++ MVP]]

PufferFish wrote:

fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c' , line 148)

This code compiled and ran OK under VC6 (SP5). We're currently
evaluating our MSDN version of .NET2003 with compiles under both
versions to check that everything still works OK under the new
compiler before doing a full upgrade. With the #pragmas around the
code, the code still compiles OK under both versions but I was
curious as to whether there is a fix available for this problem or if
there are any more details?

There are no published bug fixes for VS.NET 2003. There may be a hotfix
available for this particular ICE, but you'd have to contact product support
to find out - only PSS can give out hotfixes.

-cd

[Julie]

"Carl Daniel [VC++ MVP]" wrote:

PufferFish wrote:

fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\main.c' , line 148)

This code compiled and ran OK under VC6 (SP5). We're currently
evaluating our MSDN version of .NET2003 with compiles under both
versions to check that everything still works OK under the new
compiler before doing a full upgrade. With the #pragmas around the
code, the code still compiles OK under both versions but I was
curious as to whether there is a fix available for this problem or if
there are any more details?

There are no published bug fixes for VS.NET 2003. There may be a hotfix
available for this particular ICE, but you'd have to contact product support
to find out - only PSS can give out hotfixes.

-cd

This policy of only providing fixes after going through (paid! then refunded)
support makes no sense to me.

[PufferFish]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:ek*************@TK2MSFTNGP12.phx.gbl...

There are no published bug fixes for VS.NET 2003. There may be a hotfix
available for this particular ICE, but you'd have to contact product support to find out - only PSS can give out hotfixes.

Ok, that's pretty much what I thought -- I went through the Microsoft
Support web site looking for patches, fixes, etc. I'll let this thread soak
in for a few days to see if anyone knows of a PSS fix and then contact
Microsoft if not.

Many thanks for your reply,

PufferFish.

[Carl Daniel [VC++ MVP]]

Julie wrote:

This policy of only providing fixes after going through (paid! then
refunded) support makes no sense to me.

Don't tell me - tell Microsoft.

-cd

[Adam Clauss]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam > wrote in message
news:ec**************@tk2msftngp13.phx.gbl...

Don't tell me - tell Microsoft.

-cd

You'd probably have to pay to tell them ;)

--
Adam Clauss
ca*****@tamu.edu

[Steve McLellan]

"PufferFish" <tropical_puffer_fish@ab_so_lutely_no_where> wrote in message
news:Ox**************@TK2MSFTNGP12.phx.gbl...

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:ek*************@TK2MSFTNGP12.phx.gbl...

There are no published bug fixes for VS.NET 2003. There may be a hotfix
available for this particular ICE, but you'd have to contact product support

to find out - only PSS can give out hotfixes.

Ok, that's pretty much what I thought -- I went through the Microsoft
Support web site looking for patches, fixes, etc. I'll let this thread

soak in for a few days to see if anyone knows of a PSS fix and then contact
Microsoft if not.

Many thanks for your reply,

You still probably wouldn't be able to get hold of a fix if there is one
without contacting Microsoft - such is the bizarre nature of the system. If
you need it fixing now, you might as well get in touch with them now.

Steve

[Julie]

"Carl Daniel [VC++ MVP]" wrote:

Julie wrote:

This policy of only providing fixes after going through (paid! then
refunded) support makes no sense to me.

Don't tell me - tell Microsoft.

-cd

Don't get me wrong -- I wasn't harping on you in the least, just expressing it
to the 'world'.

[billr]

>

You still probably wouldn't be able to get hold of a fix if there is one
without contacting Microsoft - such is the bizarre nature of the system. If
you need it fixing now, you might as well get in touch with them now.

But be prepared for them to ask you for a business case indicating how this
bug affects your business before they even consider providing a fix at all :o(

I'm not sour, but they still haven't fixed the MSXML.dll for WinCE -and of
course now they certainly won't.