Re: internal compiler error in C++ front end

Re: internal compiler error in C++ front end

[Mark Mitchell]

Joe --

>    #include <vector>
>    vector<int> v(3,5);
>
>    I've verified that the crash occurs on both Linux and Solaris/sparc.
>
>    The message is
>
>    /usr/local/egcs/include/g++/vector.h:103: Internal compiler error 97.
>    /usr/local/egcs/include/g++/vector.h:103: Please submit a full bug report
>    to `egcs-bugs@cygnus.com'.

  Sorry it took me so long to get back to you about this.  I've
appended a patch below.  In this case, and in the vector<double> v(3,
5) and vector<double> v(3.0, 3.0) cases below we were (correctly)
using the vector(InputIterator i1, InputIterator i2) constructor, and
blowing up when looking for the nested name iterator_category in the
type int/double, which isn't an aggregate.

  To get the meaning you desire, you have to say:

    vector<int> v((size_t) 3, 5);

  I don't know where this leaves you if you have a vector<size_t>!
  
>    vector<double> v(5, 3.0);
>
>    works fine.
>
>    vector<double> v(3.0, 5);

  Here, we're matching vector<double>::vector(int, double), believe it
or not, so this makes a vector of three elements, each 5.0.

>
>    is quietly accepted, but seems bogus.  I suppose the compiler can
>    assume InputIterator == double, but this seems strange.
>
>    does not crash, but
>
>    vector<double> v(3, 5);
>
>    does: so does the illegal
>    vector<double> v(3.0, 3.0);

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Fri Oct  3 10:42:37 1997  Mark Mitchell  <mmitchell@usa.net>

	* decl.c (make_typename_type): Do not try to call lookup_field for
	non-aggregate types.

Index: gcc/cp/decl.c
===================================================================
RCS file: /home/mitchell/Repository/egcs/gcc/cp/decl.c,v
retrieving revision 1.1.1.9
diff -c -p -r1.1.1.9 decl.c
*** decl.c	1997/10/02 01:41:35	1.1.1.9
--- decl.c	1997/10/03 17:37:40
*************** make_typename_type (context, name)
*** 4340,4346 ****
    if (! uses_template_parms (context)
        || context == current_class_type)
      {
!       t = lookup_field (context, name, 0, 1);
        if (t == NULL_TREE)
  	{
  	  cp_error ("no type named `%#T' in `%#T'", name, context);
--- 4340,4350 ----
    if (! uses_template_parms (context)
        || context == current_class_type)
      {
!       if (IS_AGGR_TYPE (context))
! 	t = lookup_field (context, name, 0, 1);
!       else
! 	t = NULL_TREE;
! 
        if (t == NULL_TREE)
  	{
  	  cp_error ("no type named `%#T' in `%#T'", name, context);
Index: gcc/testsuite/g++.old-deja/g++.pt/typename3.C
===================================================================
RCS file: typename3.C
diff -N typename3.C
*** /dev/null	Mon Dec 31 20:00:00 1979
--- typename3.C	Fri Oct  3 10:50:29 1997
***************
*** 0 ****
--- 1,17 ----
+ // Build don't link:
+ // GROUPS passed templates
+ template <class T>
+ struct bar { 
+   typedef typename T::baz baz;
+ };
+ 
+ template <class T>
+ void foo(T)
+ {
+   bar<T>::baz(); // ERROR - T is int.
+ }
+ 
+ void foobar()
+ {
+   foo(3);
+ }

Re: internal compiler error in C++ front end

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

> What is DTRT?

Do The Right Thing.

Jason

Re: internal compiler error in C++ front end

[Joe Buck]

> > It seems that there is some confusion between vector<T>(size_type,const T&)
> > and the template member vector<T>(Iterator,Iterator).  The odd thing
> > is that for vector<int>(32,3) the second seems in some ways a better match,
> > but STL is banking on the first one being chosen! (to get a vector of
> > 32 elements with value 3).

> I believe the plan is to make the second one DTRT in this case.

What is DTRT?

Re: internal compiler error in C++ front end

[Bob Sidebotham]

I'll bite: I'm desparate for namespace support. If someone will commit
to doing the namespace support, I'll write the STL tests: I know how
to do that, but I don't know how to do the namespace support. I'm
willing to put in effort to get the namespace support, and if that
means writing STL tests or doing other grunt work that comes along,
I'd be happy...

On the other hand, if someone gave me some pointers on how to approach
the namespace stuff, I'd be willing to give it a try...

Bob Sidebotham

You said:
>>>>>> Joe Buck <jbuck@synopsys.com> writes:
>
>> It seems that there is some confusion between vector<T>(size_type,const T&)
>> and the template member vector<T>(Iterator,Iterator).  The odd thing
>> is that for vector<int>(32,3) the second seems in some ways a better match,
>> but STL is banking on the first one being chosen! (to get a vector of
>> 32 elements with value 3).
>
>I believe the plan is to make the second one DTRT in this case.
>
>> While it's likely that this particular case would not have been
>> caught, this does suggest that the libstdc++ tests are too weak; tvector
>> does not try out even 1/10 of the vector class functionality.  Tests that
>> at least call each method of vector (and the other STL classes) at least
>> once would be a great help.  (Perhaps others already have something: the
>> ObjectSpace free tests seem too weak).
>
>Yep.  Contributions welcome.
>
>Jason

Re: internal compiler error in C++ front end

[Jan Springer]

have a look at

	http://www.ipmce.su/~fbp/stl/testsuite.html

	j.

-- 
+---------------------------------------+-----------------------+
| jan springer                          | this                  |
| student of applied computer science   |    space              |
| bauhaus-university germany            |        reserved       |
+---------------------------------------+               for     |
| jan.springer@informatik.uni-weimar.de |                 quote |
+---------------------------------------+-----------------------+

internal compiler error in C++ front end

[Mark Mitchell]

>>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:

    Joe> The following program blows up egcs (every version since at
    Joe> least 970910 through the present version):

    Joe> #include <vector> vector<int> v(3,5);

    Joe> I've verified that the crash occurs on both Linux and
    Joe> Solaris/sparc.

I'll take a look at this in the next few days.

    Joe> The message is

    Joe> /usr/local/egcs/include/g++/vector.h:103: Internal compiler
    Joe> error 97.  /usr/local/egcs/include/g++/vector.h:103: Please
    Joe> submit a full bug report to `egcs-bugs@cygnus.com'.

    Joe> vector<double> v(5, 3.0);

    Joe> works fine.

    Joe> vector<double> v(3.0, 5);

    Joe> is quietly accepted, but seems bogus.  I suppose the compiler
    Joe> can assume InputIterator == double, but this seems strange.

    Joe> does not crash, but

    Joe> vector<double> v(3, 5);

    Joe> does: so does the illegal vector<double> v(3.0, 3.0);

    Joe> It seems that there is some confusion between
    Joe> vector<T>(size_type,const T&) and the template member
    Joe> vector<T>(Iterator,Iterator).  The odd thing is that for
    Joe> vector<int>(32,3) the second seems in some ways a better
    Joe> match, but STL is banking on the first one being chosen! (to
    Joe> get a vector of 32 elements with value 3).

    Joe> While it's likely that this particular case would not have
    Joe> been caught, this does suggest that the libstdc++ tests are
    Joe> too weak; tvector does not try out even 1/10 of the vector
    Joe> class functionality.  Tests that at least call each method of
    Joe> vector (and the other STL classes) at least once would be a
    Joe> great help.  (Perhaps others already have something: the
    Joe> ObjectSpace free tests seem too weak).

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: internal compiler error in C++ front end

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

> It seems that there is some confusion between vector<T>(size_type,const T&)
> and the template member vector<T>(Iterator,Iterator).  The odd thing
> is that for vector<int>(32,3) the second seems in some ways a better match,
> but STL is banking on the first one being chosen! (to get a vector of
> 32 elements with value 3).

I believe the plan is to make the second one DTRT in this case.

> While it's likely that this particular case would not have been
> caught, this does suggest that the libstdc++ tests are too weak; tvector
> does not try out even 1/10 of the vector class functionality.  Tests that
> at least call each method of vector (and the other STL classes) at least
> once would be a great help.  (Perhaps others already have something: the
> ObjectSpace free tests seem too weak).

Yep.  Contributions welcome.

Jason

internal compiler error in C++ front end

[Joe Buck]

The following program blows up egcs (every version since at least 970910
through the present version):

#include <vector>
vector<int> v(3,5);

I've verified that the crash occurs on both Linux and Solaris/sparc.

The message is

/usr/local/egcs/include/g++/vector.h:103: Internal compiler error 97.
/usr/local/egcs/include/g++/vector.h:103: Please submit a full bug report
to `egcs-bugs@cygnus.com'.

vector<double> v(5, 3.0);

works fine.

vector<double> v(3.0, 5);

is quietly accepted, but seems bogus.  I suppose the compiler can
assume InputIterator == double, but this seems strange.

does not crash, but

vector<double> v(3, 5);

does: so does the illegal
vector<double> v(3.0, 3.0);

It seems that there is some confusion between vector<T>(size_type,const T&)
and the template member vector<T>(Iterator,Iterator).  The odd thing
is that for vector<int>(32,3) the second seems in some ways a better match,
but STL is banking on the first one being chosen! (to get a vector of
32 elements with value 3).

While it's likely that this particular case would not have been
caught, this does suggest that the libstdc++ tests are too weak; tvector
does not try out even 1/10 of the vector class functionality.  Tests that
at least call each method of vector (and the other STL classes) at least
once would be a great help.  (Perhaps others already have something: the
ObjectSpace free tests seem too weak).