Re: c++/29

Re: c++/29

[neil]

The following reply was made to PR c++/29; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: Gabriel.Dos-Reis@cmla.ens-cachan.fr, gcc-gnats@gcc.gnu.org,
  martin@loewis.home.cs.tu-berlin.de, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/29
Date: 11 Jan 2001 20:21:29 -0000

 Synopsis: Possible bug in the template instanciation machinery
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: neil
 State-Changed-When: Thu Jan 11 12:21:29 2001
 State-Changed-Why:
     Fixed recently in CVS.  I'll submit a test case soon.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=29&database=gcc
>From Theodore.Papadopoulo@sophia.inria.fr Sun Apr 01 00:00:00 2001
From: Theodore.Papadopoulo@sophia.inria.fr
To: gcc-gnats@gcc.gnu.org
Subject: c++/1917: ICE on legal code #283
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010208223847.9327.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01085.html
Content-length: 1613

>Number:         1917
>Category:       c++
>Synopsis:       ICE on legal code #283
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 08 14:46:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Theo Papadopoulo
>Release:        gcc-2.97 (020801)
>Organization:
>Environment:
Linux 2.2.18 but certainly a frontend bug.
>Description:
It believe this is related to PR885 but the testcase is much simpler.
This is somewhat annoying as the example is simplified from QT.

If we remove A or B or the virtual destructors the bug disappears.
>How-To-Repeat:
Just compile it. You should get:
mururoa->g++ tutu.C
tutu.C: In function `int f(int)':
tutu.C:11: Internal error #283.
tutu.C:11: Internal compiler error in instantiate_template, at cp/pt.c:7595
Please submit a full bug report.
 See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="TempBug.C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TempBug.C"

Ly8gQnVpbGQgZG9uJ3QgbGluazoKLy8gT3JpZ2luOiBUaGVvIFBhcGFkb3BvdWxvIDxUaGVvZG9y
ZS5QYXBhZG9wb3Vsb0Bzb3BoaWEuaW5yaWEuZnI+CgpzdHJ1Y3QgQSB7IHZpcnR1YWwgfkEoKTsg
fTsKc3RydWN0IEIgeyB2aXJ0dWFsIH5CKCk7IH07CgpzdHJ1Y3QgQzogcHVibGljIEEsQiB7fTsK
CnRlbXBsYXRlIDxjbGFzcyBUWVBFPgppbmxpbmUgVFlQRQpzcXIoY29uc3QgVFlQRSYgeCkgewog
ICAgcmV0dXJuIDE7Cn0KaW50IGYoY29uc3QgaW50IHQpIHsgcmV0dXJuIHNxcih0KTsgfQo=
>From nathan@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: nathan@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1547
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010110161604.18121.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00162.html
Content-length: 549

The following reply was made to PR c++/1547; it has been noted by GNATS.

From: nathan@gcc.gnu.org
To: dm@virus.ru, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1547
Date: 10 Jan 2001 16:13:05 -0000

 Synopsis: problems with templates and inheritance from virtual class
 
 State-Changed-From-To: open->feedback
 State-Changed-By: nathan
 State-Changed-When: Wed Jan 10 08:13:05 2001
 State-Changed-Why:
     No sample code was provided - please provide it.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1547&database=gcc
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/306
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010116210600.23042.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00387.html
Content-length: 1152

The following reply was made to PR c++/306; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, heinlein@informatik.uni-ulm.de,
  martin@loewis.home.cs.tu-berlin.de, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/306
Date: 16 Jan 2001 20:57:43 -0000

 Synopsis: Internal compiler error in gcc-2.95.2
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: neil
 State-Changed-When: Tue Jan 16 12:57:43 2001
 State-Changed-Why:
     This appears to be fixed in CVS:-
     
     bash-2.04$ g++ /tmp/1.ii 
     In file included from ctrl:52:
     /usr/include/stdlib.h:66: declaration does not declare anything
     ctrl:356:14: warning: expected to return to line number 53
     ctrl:524:14: warning: expected to return to line number 54
     string:143:15: warning: expected to return to line number 8
     str: In function `void beg1()':
     str:9: ambiguous overload for `const char[2] + Str_sr&' operator
     str:9: candidates are: operator+(const char*, int) <builtin>
     str:64:                 Str_sr operator+(Str_sr, Str_sr)
     bash-2.04$ 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=306&database=gcc
>From bumgard@roguewave.com Sun Apr 01 00:00:00 2001
From: Greg Bumgardner <bumgard@roguewave.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: RE: libstdc++/1884: Some .tcc files not included because _GLIBCPP_NO_TEMPLATE_EXPORT macro is not defined
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010206074600.23364.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00989.html
Content-length: 1814

The following reply was made to PR libstdc++/1884; it has been noted by GNATS.

From: Greg Bumgardner <bumgard@roguewave.com>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>, 
	"'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>
Cc:  
Subject: RE: libstdc++/1884: Some .tcc files not included because _GLIBCPP
	_NO_TEMPLATE_EXPORT macro is not defined
Date: Mon, 5 Feb 2001 23:22:40 -0800 

 After further investigation, it appears that the unresolved symbols in the
 template instantiations were the result of several
 apparent defects :
 
 1) The #include for bits/basic_ios.tcc in bits/basic_ios.h is commented out.
 
 2) The #define for _GLIBCPP_FULLY_COMPLIANT_HEADERS in c++config(.h) is
 commented out.
 
 3) The definitions for the std::__basic_file template (used and declared in
 bits/basic_file.h) are located in the c_io_stdio.cc file in the source
 config directory.  These definitions are not available for user
 instantiation. Why is this???
 
 Anyway the _GLIBCPP_NO_TEMPLATE_EXPORT macro was not the problem, so this
 defect report may be closed and I'll replace it with three new ones.
 
 -g.b.
 
 
 
 > -----Original Message-----
 > From: gcc-gnats@gcc.gnu.org [ mailto:gcc-gnats@gcc.gnu.org ]
 > Sent: Monday, February 05, 2001 9:56 PM
 > To: bumgard@roguewave.com
 > Subject: Re: libstdc++/1884: Some .tcc files not included because
 > _GLIBCPP_NO_TEMPLATE_EXPORT macro is not defined
 > 
 > 
 > Thank you very much for your problem report.
 > It has the internal identification `libstdc++/1884'.
 > The individual assigned to look at your
 > report is: unassigned. 
 > 
 > >Category:       libstdc++
 > >Responsible:    unassigned
 > >Synopsis:       Some .tcc files not included because 
 > _GLIBCPP_NO_TEMPLATE_EXPORT macro is not defined
 > >Arrival-Date:   Mon Feb 05 21:56:00 PST 2001
 > 
>From bernds@redhat.com Sun Apr 01 00:00:00 2001
From: Bernd Schmidt <bernds@redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/1534: ICE probably due to uninitialized memory
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010102184600.12099.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00007.html
Content-length: 1592

The following reply was made to PR c/1534; it has been noted by GNATS.

From: Bernd Schmidt <bernds@redhat.com>
To: <drepper@redhat.com>
Cc: <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: c/1534: ICE probably due to uninitialized memory
Date: Tue, 2 Jan 2001 18:38:25 +0000 (GMT)

 On 2 Jan 2001 drepper@redhat.com wrote:
 >   gcc -c -O2 maccess.i
 >
 > Don't use -O nor -O3.  I hope it's reproducible for whoever handles this.  I get
 >
 > drepper@myware build$ gcc -c -O2 maccess.i
 > maccess.i: In function `SetBitMem':
 > maccess.i:688: Virtual array reg_n_info[73]: element 73 out of bounds
 > maccess.i:688: Internal compiler error in mark_set_1, at flow.c:4760
 
 This patch fixes it for me.  I'll check it in once bootstrap & tests
 complete.
 
 
 Bernd
 
 	* builtins.c (expand_builtin_return_addr): Don't use MEM_ALIAS_SET on
 	a REG rtx.
 
 Index: builtins.c
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/builtins.c,v
 retrieving revision 1.83
 diff -u -p -r1.83 builtins.c
 --- builtins.c	2000/12/28 02:45:37	1.83
 +++ builtins.c	2001/01/02 18:36:52
 @@ -431,8 +431,9 @@ expand_builtin_return_addr (fndecl_code,
        tem = DYNAMIC_CHAIN_ADDRESS (tem);
  #endif
        tem = memory_address (Pmode, tem);
 -      tem = copy_to_reg (gen_rtx_MEM (Pmode, tem));
 +      tem = gen_rtx_MEM (Pmode, tem);
        MEM_ALIAS_SET (tem) = get_frame_alias_set ();
 +      tem = copy_to_reg (tem);
      }
 
    /* For __builtin_frame_address, return what we've got.  */
 
>From bkoz@gc Sun Apr 01 00:00:00 2001
From: bkoz@gc
To: egcs@cygnus.com
Cc: gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/1967
Date: Sun, 01 Apr 2001 00:00:00 -0000
X-SW-Source: 2001-q1/msg02340.html
Content-length: 74

The following reply was made to PR libstdc++/1967; it has been noted by G
>From pme@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: pme@gcc.gnu.org
To: pme@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/660
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010126010602.24013.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00721.html
Content-length: 888

The following reply was made to PR libstdc++/660; it has been noted by GNATS.

From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, olivier@zipworl.com.au,
  pme@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/660
Date: 26 Jan 2001 00:57:40 -0000

 Synopsis: Failure to build g++ with libstdc++-v3 on i686-pc-linux-gnu
 
 Responsible-Changed-From-To: unassigned->pme
 Responsible-Changed-By: pme
 Responsible-Changed-When: Thu Jan 25 16:57:40 2001
 Responsible-Changed-Why:
     Waiting for feedback.
 State-Changed-From-To: open->feedback
 State-Changed-By: pme
 State-Changed-When: Thu Jan 25 16:57:40 2001
 State-Changed-Why:
     Is this problem still occuring for you?  Note that with current CVS,
     -v3 is enabled by default.  Also, building in a subdirectory of the source tree is not recommended.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=660&database=gcc
>From pme@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: pme@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: libstdc++/1005
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010127023601.390.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00763.html
Content-length: 967

The following reply was made to PR libstdc++/1005; it has been noted by GNATS.

From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, klima@iue.tuwien.ac.at, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/1005
Date: 27 Jan 2001 02:27:22 -0000

 Synopsis: setw() does not work with doubles
 
 State-Changed-From-To: open->closed
 State-Changed-By: pme
 State-Changed-When: Fri Jan 26 18:27:22 2001
 State-Changed-Why:
     
     Using current CVS:
     
         % cat 1005.cc
     
         #include <iostream>
         #include <iomanip>
     
         int main ()
         {
             std::cout << std::setw(20) << 2.3 << std::endl;
         }
     
         % g++ 1005.cc
         % ./a.out
                          2.3
         %
     
     So this appears to be fixed.
     
     This also runs correctly when piped through less(1), but
     that's difficult to show in a text editor.  :-)
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1005&database=gcc
>From rth@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: rth@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/763
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010216043601.18242.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01323.html
Content-length: 544

The following reply was made to PR optimization/763; it has been noted by GNATS.

From: rth@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, richard.mitton@bigfoot.com
Cc:  
Subject: Re: optimization/763
Date: 16 Feb 2001 04:35:21 -0000

 Synopsis: GCC generates incorrect code when optimising
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: rth
 State-Changed-When: Thu Feb 15 20:35:20 2001
 State-Changed-Why:
     User can't recreate test case.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=763&database=gcc