Re: c++/888

Re: c++/888

[lerdsuwa]

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

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  schmid@snake.iap.physik.tu-darmstadt.de
Cc:  
Subject: Re: c++/888
Date: 8 Feb 2001 08:08:17 -0000

 Synopsis: ice #122 error in finish_function, at cp/decl.c:14147
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: lerdsuwa
 State-Changed-When: Thu Feb  8 00:08:16 2001
 State-Changed-Why:
     Confirm as a bug.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=888&database=gcc
>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++/1520
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010115092601.21801.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00303.html
Content-length: 888

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

From: nathan@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, magnus@gol.com, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1520
Date: 15 Jan 2001 09:24:17 -0000

 Synopsis: cout prints in the wrong order.
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: nathan
 State-Changed-When: Mon Jan 15 01:24:17 2001
 State-Changed-Why:
     The 2nd and 3rd attachments are the real code. This invokes an
     unspecified evaluation ordering on
     	cout << "first" << examine ();
     which reduces to
     	op<< (op<< (cout, "first), examine ());
     the arguments to the outer op<< call are evaluated in an
     unspecified order, hence any side effects of examine (), 
     can occur before or after any side effects of the inner
     op<< call.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1520&database=gcc
>From gerald@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: gerald@gcc.gnu.org
To: jsm28@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: web/973
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010122103601.18428.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00579.html
Content-length: 621

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

From: gerald@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, jsm28@gcc.gnu.org, law@gcc.gnu.org
Cc:  
Subject: Re: web/973
Date: 22 Jan 2001 10:33:03 -0000

 Synopsis: Junk in the FOM
 
 Responsible-Changed-From-To: law->jsm28
 Responsible-Changed-By: gerald
 Responsible-Changed-When: Mon Jan 22 02:33:03 2001
 Responsible-Changed-Why:
     Joseph offered to take care of this once he has appropriate
     write access, which should be the case now according to Jeff.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=973&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++/646
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010208210601.18746.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01078.html
Content-length: 1362

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

From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, kzhang@vill.com, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/646
Date: 8 Feb 2001 21:00:41 -0000

 Synopsis: stl map hangs while erasing end()
 
 State-Changed-From-To: open->closed
 State-Changed-By: pme
 State-Changed-When: Thu Feb  8 13:00:41 2001
 State-Changed-Why:
     Stroustrup was wrong.
     
     (How often do I get to say *that*?  :-)
     
     Given a container c, I don't know whether c.erase(c.end()) used to be
     valid, but it isn't, and I suspect it never was.  The constraints on
     the single-iterator-argument of erase() include that the iterator may
     be dereferenced, which end() cannot be.  In the current implementation
     of map<>, this leads to an infinite loop as we search for a non-NULL
     child... of end()...
     
     Somewhere around the 10th or 11th printing, Stroustrup notes this change
     in his errata list:
     
         pg 489 replace "Erasing end() is harmless." by "A call m.erase(b,e)
         where e is m.end() is harmless (provided b refers to an element of
         m or is m.end()). However, a call m.erase(p) where p is m.end() is a
         serious error that could corrupt the container."
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=646&database=gcc
>From anonymous@sourceware.cygnus.com Sun Apr 01 00:00:00 2001
From: anonymous@sourceware.cygnus.com
To: gcc-gnats@gcc.gnu.org
Subject: c/2164: ICE on NetBSD/i386, gcc 3.0 20010303 (prerelease)
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010303204303.26710.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01979.html
Content-length: 2397

>Number:         2164
>Category:       c
>Synopsis:       ICE on NetBSD/i386, gcc 3.0 20010303 (prerelease)
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 03 12:46:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Krister Walfridsson
>Release:        gcc version 3.0 20010303 (prerelease)
>Organization:
>Environment:
NetBSD/i386 1.5S (built as a.out)
>Description:
GCC CVS:ed today from the 3.0 branch gives me an ICE when I
try to compile the NetBSD kernel:

gcc -O2 ice.c
ice.c: In function `foo':
ice.c:26: Internal error: Segmentation fault

where ice.c is the small file below (that has been cut out
from the NetBSD sys/dev/ic/aic6360.c)

   /Krister


#define   I386_BUS_SPACE_IO       0
#define bus_space_read_multi_1(t, h, o, a, c)                           \
do {                                                                    \
        if ((t) == I386_BUS_SPACE_IO) {                                 \
                insb((h) + (o), (a), (c));                              \
        } else {                                                        \\x1a
                void *dummy1;                                           \
                int dummy2;                                             \
                int __x __asm__("%eax");                                \
                __asm __volatile("                                      \
                        cld                                     ;       \
                1:      movb (%1),%%al                          ;       \
                        stosb                                   ;       \
                        loop 1b"                                :       \
                    "=&a" (__x), "=D" (dummy1), "=c" (dummy2)   :       \
                    "r" ((h) + (o)), "1" ((a)), "2" ((c))       :       \
                    "memory");                                          \
        }                                                               \
} while (0)


void
foo(void)
{
	char chip_id[32];
	bus_space_read_multi_1(0, 0, 0, chip_id, 31);
}
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 From: cato@df.lth.se
 Reply-To: cato@df.lth.se
 X-Send-Pr-Version: gnatsweb-2.6 (1.135)
 X-GNATS-Notify: 
 
 
 

Re: c++/888

[lerdsuwa]

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

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  schmid@snake.iap.physik.tu-darmstadt.de
Cc:  
Subject: Re: c++/888
Date: 11 Feb 2001 12:23:37 -0000

 Synopsis: ice #122 error in finish_function, at cp/decl.c:14147
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Sun Feb 11 04:23:37 2001
 State-Changed-Why:
     Fixed in the CVS.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=888&database=gcc