Visual C++ 7.1 INTERNAL COMPILER ERROR

[Alf P. Steinbach]

// As usual the error message directs one to the report the bug.
//
// And as usual there is absolutely no way to do so without paying for
// the privilege...
//
// Or using three or four hours to find the _current_ reporting page...


#include <vector>
#include <iostream>

template< typename T, size_t N >
struct ArrayHolder
{
T elem[N];
};

template< typename T >
class VectorImpl
{
private:
std::vector<T> elem;
public:
template< size_t N >
VectorImpl( T const (&values)[N] ): elem( values, values+N ) {}

T& operator[]( size_t i ){ return elem.at( i ); }
T const& operator[]( size_t i ) const { return elem.at( i ); }
};

template< typename T >
class Vector: public VectorImpl< T >
{
public:
template< size_t N >
VectorImpl( T const (&values)[N] ): VectorImpl( values ) {}
};

int main()
{
typedef ArrayHolder<double, 6> DoubleArray6;
static DoubleArray6 const x = { 10, 20, 30, 40, 50, 60 };
static DoubleArray6 const xArray[] = { x };

Vector<DoubleArray6> v( xArray );
for( size_t i = 0; i < 6; ++i )
{
std::cout << v[0].elem << std::endl;
}
}

 

[Unforgiven]

#include <vector>
#include <iostream>

template< typename T, size_t N >
struct ArrayHolder
{
T elem[N];
};

template< typename T >
class VectorImpl
{
private:
std::vector<T> elem;
public:
template< size_t N >
VectorImpl( T const (&values)[N] ): elem( values, values+N ) {}

T& operator[]( size_t i ){ return elem.at( i ); }
T const& operator[]( size_t i ) const { return elem.at( i ); }
};

template< typename T >
class Vector: public VectorImpl< T >
{
public:
template< size_t N >
VectorImpl( T const (&values)[N] ): VectorImpl( values ) {}

The fact that it causes an internal compiler error may be a bit strange, but
it is your code that's at fault. You define a constructor with a name that
does not match the class it's in, and furthermore you try to use the base
class constructor without specifying template arguments.

The line should be:

Vector(T const (&values)[N] ) : VectorImpl<T>(values) {}

The code compiles fine then.

};

int main()
{
typedef ArrayHolder<double, 6> DoubleArray6;
static DoubleArray6 const x = { 10, 20, 30, 40, 50, 60
}; static DoubleArray6 const xArray[] = { x };

Vector<DoubleArray6> v( xArray );
for( size_t i = 0; i < 6; ++i )
{
std::cout << v[0].elem << std::endl;
}
}

 

[Rob Williscroft]

Alf P. Steinbach wrote in in
comp.lang.c++:

Subject: Visual C++ 7.1 INTERNAL COMPILER ERROR

// As usual the error message directs one to the report the bug.
//
// And as usual there is absolutely no way to do so without paying for
// the privilege...
//
// Or using three or four hours to find the _current_ reporting page...

Try posting to:

news://microsoft.public.dotnet.languages.vc

Hopefully someone from MS can pick it up from there.

[snip]

template< typename T >
class Vector: public VectorImpl< T >
{
public:
template< size_t N >
VectorImpl( T const (&values)[N] ): VectorImpl( values ) {}

You probably know this already but:

};

[snip]

I have my editor setup so I can send my code through (currently)
5 (*) different compilers, really helps with ICE's.

*) Maybe 4, its rare these days that I use borland 5.4 for more than
a cheap laugh. (just checked it ICE'd on the fixed code).


Rob.

 

[Alf P. Steinbach]

The fact that it causes an internal compiler error may be a bit strange, but
it is your code that's at fault.

<teaspoon mode>
The user's input is _never_ at fault for a program crash.

A program, such as a compiler, shall never crash no matter what input
it is given.

For a compiler that's even more critical than for other programs.
</teaspoon mode>

Did you understand this?

What is your real name?

 

[Unforgiven]

<teaspoon mode>
The user's input is _never_ at fault for a program crash.

It's not what I meant. Your code was wrong, but the compiler shouldn't have
given an ICE, I'll agree to that. Although if we must get technical, an ICE
is not a crash. It's just the compiler saying "something is in this code
that makes me unable to compile it, but I haven't a clue what".

A program, such as a compiler, shall never crash no matter what input
it is given.

For a compiler that's even more critical than for other programs.

I tend to be somewhat forgiving toward compiler writers, since I've written
one, so I know how #*$^# difficult it is. Truely, if writing an optimizing
compiler for a simple Pascal dialect as I was doing was that difficult, I'd
probably rather try to perform open hart surgery on myself than write a C++
compiler. ^_^ (please take this in the non-serious way it's intended)

</teaspoon mode>

Did you understand this?

Yes. What I don't understand is why you saw it necessary to lecture me.

What is your real name?

How is that relevant?

 

[Alf P. Steinbach]

It's not what I meant. Your code was wrong, but the compiler shouldn't have
given an ICE, I'll agree to that. Although if we must get technical, an ICE
is not a crash. It's just the compiler saying "something is in this code
that makes me unable to compile it, but I haven't a clue what".

An ICE is a crash.

Usually it's an exception (e.g. due to indexing internal tables outside
allowed range) that's caught in the outermost top-level exception handler.

It's always a bug, and that's why it should always be reported, and why
the folks at Microsoft that made the compiler chose to include guidelines
for doing so in the error message -- then marketing or whomever have
chosen to effectively remove the actual possibility of reporting the bug
by moving the reporting page around to different URLs, by not including any
link to it in the page one is directed to, by giving the impression that
no such reporting page even exists, and so on; it's just Bad Managers.

I tend to be somewhat forgiving toward compiler writers, since I've written
one

Well who hasn't. Writing a Pascal compiler, as you state you have done, was
part of my basic education. I think it's almost always included in CS.

How is that relevant?

It is a coward's way to hide behind anonymity and state that other people
are wrong or at fault for something.

 

[Unforgiven]

And fwiw, Borland C++Builder 5 may not give an ICE with the incorrect code,
it actually fails to compile the *correct* code with:
[C++ Error] Unit1.cpp(43): E2034 Cannot convert 'const
ArrayHolder<double,6>' to 'double'
(that's the line: "static DoubleArray6 const xArray[] = { x };" fyi)

Visual C++ 6 is even worse btw:
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(25)
: error C2265: '<Unknown>' : reference to a zero-sized array is illegal
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(29)
: see reference to class template instantiation 'VectorImpl<T>' being
compiled
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(36)
: error C2265: '<Unknown>' : reference to a zero-sized array is illegal
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(37)
: see reference to class template instantiation 'Vector<T>' being compiled
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(43)
: error C2440: 'initializing' : cannot convert from 'const struct
ArrayHolder<double,6>' to 'double'
No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(25)
: error C2265: '<Unknown>' : reference to a zero-sized array is illegal
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(33)
: see reference to class template instantiation 'VectorImpl<struct
ArrayHolder<double,6> >' being compiled
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(45)
: see reference to class template instantiation 'Vector<struct
ArrayHolder<double,6> >' being compiled
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(36)
: error C2265: '<Unknown>' : reference to a zero-sized array is illegal
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(45)
: see reference to class template instantiation 'Vector<struct
ArrayHolder<double,6> >' being compiled
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(45)

::Vector<struct ArrayHolder<double,6> >(const class Vector

<struct ArrayHolder<double,6> > &)' : cannot convert parameter 1 from 'const
struct ArrayHolder<double,6> [1]' to 'const class Vector<struct
ArrayHolder<double,6> > &'
Reason: cannot convert from 'const struct ArrayHolder<double,6> [1]'
to 'const class Vector<struct ArrayHolder<double,6> >'
No constructor could take the source type, or constructor overload
resolution was ambiguous
D:\My Documents\Visual Studio
Projects\DCTSDK\DataConversieTool_14_8_2002\ProjectDataconversietool\cpptestv6\cpptestv6.cpp(50)
: warning C4508: 'main' : function should return a value; 'void' return type
assumed

 

[Unforgiven]

It's always a bug, and that's why it should always be reported, and
why
the folks at Microsoft that made the compiler chose to include
guidelines for doing so in the error message -- then marketing or
whomever have chosen to effectively remove the actual possibility of
reporting the bug
by moving the reporting page around to different URLs, by not
including any link to it in the page one is directed to, by giving
the impression that
no such reporting page even exists, and so on; it's just Bad Managers.

Use the relevant microsoft.public group. The VC++ team reads that. It's the
best way to get the bug through.

Well who hasn't. Writing a Pascal compiler, as you state you have
done, was part of my basic education. I think it's almost always
included in CS.

I know tons of people that haven't written a compiler. Mostly these are
people who are in the IT industry without having a 'real' CS education. They
tend to outnumber the real CS people. Fwiw, for me it was also part of my CS
education. Also one of the most fun assignments we've had, actually.

It is a coward's way to hide behind anonymity and state that other
people are wrong or at fault for something.

It is also the way to avoid spam. If you must know, my real name is Sven
Groot. I'd post here under my real name, but this group is on the same
server as several other groups where I definitely don't want to do that. On
the MS groups, where I post via msnews.microsoft.com, I do use my real name.

 

[Julie]

It is a coward's way to hide behind anonymity and state that other people
are wrong or at fault for something.

Alf, take your presumptive crap elsewhere.

 

[Julie]

<teaspoon mode>
The user's input is _never_ at fault for a program crash.

A program, such as a compiler, shall never crash no matter what input
it is given.

For a compiler that's even more critical than for other programs.
</teaspoon mode>

Did you understand this?

<rubber-coated baby spoon mode>

What does your compiler crash have to do w/ clc++?

</rubber-coated baby spoon mode>

 

[Alf P. Steinbach]

<rubber-coated baby spoon mode>

What does your compiler crash have to do w/ clc++?

</rubber-coated baby spoon mode>

First, it isn't my crash, it's a Visual C++ 7.1 crash (ICE).

Second, disregarding the version (it's the latest) that means it is
a crash in the most used C++ compiler.

Third, it's in the interest of the C++ community to get Microsoft up to
date in its C++ compiler technology, for which it's important to get back
in order an open channel for ICE reporting, which other vendors have, and
for which it's important to bring those bugs out in the open, known.



Off-topic: you're way out of line, Julie, and the attempt at sarcasm
does not help.

And that's not something new with you.

 

[Jerry Coffin]

// As usual the error message directs one to the report the bug.
//
// And as usual there is absolutely no way to do so without paying for
// the privilege...
//
// Or using three or four hours to find the _current_ reporting page...

Perhaps this will save some of that time:

http://support.microsoft.com/default.aspx?scid=/support/visualc/report/default.asp

OTOH, MS apparently already has the next version of the compiler
fairly functional, so it may be open to question how much good
reporting it at this point really does -- if it's already been fixed,
none, but if it hasn't, the timing may be nearly ideal.

 

[Alf P. Steinbach]

* (e-mail address removed) (Jerry Coffin) schriebt:

Perhaps this will save some of that time:

http://support.microsoft.com/default.aspx?scid=/support/visualc/report/default.asp

Thank you , but that is not the _current_ page :-(.

It is in fact an old page, referring to Windows versions up to W2K only.

And submitting a report (which I tried just now) only results in
"Sorry, the page you requested is not available" after typing in everything
and clicking the button.

Now that's what I remember from far back for that page and other Visual C++
bug reporting pages; they seem move it around, never at a constant URL.

I once apparently succeeded in submitting a bug report because someone from
Microsoft (I think) provided an URL to the then _current_ bug reporting page,
but to find it -- well, that's the three or four hours mentioned above...

 

[Jørn Dahl-Stamnes]

<teaspoon mode>
The user's input is _never_ at fault for a program crash.

Agree. I only once got a severe number of INTERNAL COMPILER ERROR from Visual
C++. It was after I got a new motherboard with new memory... it was bad memory
that cause all the errors...

 

[Julie]

// As usual the error message directs one to the report the bug.
//
// And as usual there is absolutely no way to do so without paying for
// the privilege...
//
// Or using three or four hours to find the _current_ reporting page...

(Still trying to figure out how this is on-topic in this forum...)

Call paid support.

Tell them it is a bug, and they will credit the initial charge.

Done.

 

[Default User]

First, it isn't my crash, it's a Visual C++ 7.1 crash (ICE).

So, how is that on-topic?



Brian Rodenborn

 

[Alf P. Steinbach]

So, how is that on-topic?

Read a FAQ on quoting.

 

[Alf P. Steinbach]

(Still trying to figure out how this is on-topic in this forum...)

Well, that's a bit complicated, so bear with me.

For newbies we use a simple rule, because they need a simple rule they
can grasp and follow mechanically: this group is only about standard C++.

In practice you will have seen that e.g. questions about Boost are "allowed",
whereas questions about e.g. ATL or SuperDuperPlotter are less welcome, and
questions that only have to do with tool usage are scorned, burned, killed.

The current fewer of topicality enforcement originated many years ago when
this group more or less was hijacked by Windows programmer newbies, leading
to the establishment of [comp.lang.c++.moderated] to filter out the flak.

So in effect any article that would be accepted in [comp.lang.c++.moderated]
is on-topic here, but that's a bit hard to explain to newbies. For the main
rationale is something that requires judgment. Namely, whether an article is
of common interest (affects many, or many can learn from it), or not. But one
can not require such judgement from someone who doesn't even know whether
something is part of C++ or has to do with programming at all. So for newbies
a simplified hard-and-fast rule is used; but I think you'll perhaps understand
this if you think about whether [comp.lang.c++.moderated] would accept it.

Call paid support.

Tell them it is a bug, and they will credit the initial charge.

Done.

I don't trust them... ;-)

 

[Julie]

:
[snip]

In practice you will have seen that e.g. questions about Boost are "allowed"
whereas questions about e.g. ATL or SuperDuperPlotter are less welcome, and
questions that only have to do with tool usage are scorned, burned, killed.

Yes, we have seen that regarding Boost, however _I_ consider Boost questions
off-topic (Boost has its own list/newsgroup, no need to clutter up this forum
w/ such stuff), unless it specifically is about the language or a standard
construct or idiom, and if that is the case, then _I_ don't exclude any 3rd
party code library (such as the mentioned ATL, etc.).

whereas questions about e.g. ATL or SuperDuperPlotter are less welcome, and
questions that only have to do with tool usage are scorned, burned, killed.
[snip]

Call paid support.

Tell them it is a bug, and they will credit the initial charge.

Done.

I don't trust them... ;-)

Personally, I don't understand (or attempt to interpret) emoticons ... are you
serious in that you don't trust them? I've done it several times, and never
had a problem. In the short and long run for me, it was much more
cost-effective than wasting hours (of billable) time trying to find their free
support options...

 

[Unforgiven]

Because I know microsoft.public.dotnet.languages.vc is monitored by someone
with the power to submit bug reports to the Whidbey team, I posted the
following message there. I took the liberty of breaking the code down to the
minimal still failing case.

----

This was posted by someone in comp.lang.c++, and later in
microsoft.public.vstudio.general, but since I know Carl is in this group,
and he's the one that should read this, I've reposted it here. I've also
minimalised the code that causes the bug.

The bug is that the following syntax causes an Internal Compiler Error. The
code is not correct, but should produce a warning or error message, not an
ICE. It occurs when a template class mistakenly names its constructor after
a different class, and in addition uses a template type parameter followed
by 'const'. See 'example below'. The code is complete.

----CODE SAMPLE----
class SomeClassA
{
};

template<typename X>
class SomeClassB
{
public:
SomeClassA(X const &n) { }; // *
};

int main()
{
return 0;
}
----END CODE SAMPLE----

----COMPILER OUTPUT----
test2.cpp
d:\My Documents\Visual Studio Projects\cpptest\test2.cpp(9) : fatal error
C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2701)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
----END COMPILER OUTPUT----

The error occurs in the line marked // *. Remove the 'const' and the code
correctly fails to compile because it sees SomeClassA as a typename, but at
least in this situation it gives proper error messages, not an ICE. Remove
class SomeClassA, and the code compiles with "warning C4183: 'SomeClassA':
missing return type; assumed to be a member function returning 'int'".
Change the 'X' on line * into 'int', and the code compiles with the same
warning.

I'm not certain if code like this is supposed to compile according to the
standard with such a warning, or if it's supposed to fail like when the
const is removed, but I do know it shouldn't give an ICE.