public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/1710
@ 2001-04-01  0:00 James Dennett
  0 siblings, 0 replies; 2+ messages in thread
From: James Dennett @ 2001-04-01  0:00 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: James Dennett <jdennett@acm.org>
To: mdh_gcc@hotmail.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/1710
Date: Sat, 27 Jan 2001 21:25:45 +0000

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1710&database=gcc
 
 Just randomly looking in GNATS, I've checked bug 1710 with my slightly
 out-of-date gcc 2.97, and it appears to be fixed in this snapshot.
 I ran the test code from the bug database, fixed to include <iostream>
 and with some using declarations for things from std:: and it runs
 just fine.
 
 I'm not familiar with how things work; should this bug be left "open"
 until gcc 3.0 is released?  Should I volunteer to monitor it, as it is
 currently "unassigned"?
 
 Any thoughts (or silence) welcome.
 
 Regards,
 
 James Dennett <jdennett@acm.org>
 
 
 [james@jamesd james]$ gcc -v
 Reading specs from
 /usr/local/bin/../lib/gcc-lib/i386-pc-linux-gnu/2.97/specs
 Configured with: ../configure --prefix=/tmp/gcc-20001126-root/usr/local
 --enable-shared --enable-threads --disable-checking i386-pc-linux-gnu
 gcc version 2.97 20001126 (experimental)
>From jsm28@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: jsm28@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/1623
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010113202600.21440.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00258.html
Content-length: 1363

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

From: jsm28@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, jsm28@cam.ac.uk, neel@eng.sun.com,
  nobody@gcc.gnu.org
Cc:  
Subject: Re: c/1623
Date: 13 Jan 2001 20:24:39 -0000

 Synopsis: GCC allows void function to return value
 
 State-Changed-From-To: open->closed
 State-Changed-By: jsm28
 State-Changed-When: Sat Jan 13 12:24:39 2001
 State-Changed-Why:
     A warning (in this case, on by default) is a diagnostic;
     GCC is telling you about the problem with your code.
     With -pedantic-errors, it becomes an error.  To quote the
     manual:
     
        GCC always tries to compile your program if possible; it never
     gratuitously rejects a program whose meaning is clear merely because
     (for instance) it fails to conform to a standard.
     
     and
     
        * If the compiler does not produce an error message for invalid
          input, that is a compiler bug.  However, you should note that your
          idea of "invalid input" might be my idea of "an extension" or
          "support for traditional practice".
     
     So, the compiler tells you about the problem, and compiles
     the code anyway, as intended.  It's up to the programmer
     to use the warning to clean up their code.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1623&database=gcc
>From ericy@iname.com Sun Apr 01 00:00:00 2001
From: ericy@iname.com
To: gcc-gnats@gcc.gnu.org
Cc: ericy@sakura.com.tw
Subject: debug/2032: The bugs in libgcc2.c when building x86 to ARM cross compiler
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010220024723.13029.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01504.html
Content-length: 1076

>Number:         2032
>Category:       debug
>Synopsis:       The bugs in libgcc2.c when building x86 to ARM cross compiler
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 19 18:56:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     brandon yang
>Release:        gcc-20010122.tar.gz
>Organization:
>Environment:
gcc-20010122.tar.gz, binutils-010118.tar.bz2,
glibc-2.2.1.tar.gz, Red hat linux6.0 and x86 CPU
>Description:
I want to install x86 to ARM cross compiler. But some bug
appeared as follow:

/gcc/libgcc2.c : 3282 : syntax error before "once"
                     : 3286 : warning : implicit declaration of function '__gthread_once"
                     : 3294 : syntax error before "once_regsizes"
                     : 3835 : warning : implicit declaration of function
"memcpy"
make[2] : *** [libgcc/./_eh.o] Error1
make[1] : ***[libgcc.a] Error2
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: libstdc++/1710
@ 2001-04-01  0:00 pme
  0 siblings, 0 replies; 2+ messages in thread
From: pme @ 2001-04-01  0:00 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, mdh_gcc@hotmail.com, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/1710
Date: 27 Jan 2001 21:37:37 -0000

 Synopsis: strings.find_last_of() function works only if I explicitly reference the strings.c_str() function after calling it
 
 State-Changed-From-To: open->closed
 State-Changed-By: pme
 State-Changed-When: Sat Jan 27 13:37:36 2001
 State-Changed-Why:
     Thanks for your bug report.
     
     After changing the example code to include <iostream>,
     declare main() as returning 'int' (this is not an option
     in standard C++), and adding 'using' statements for
     std::string and std::cout, this code works under current
     CVS:
     
         % HOME=${HOME}///////////  ./a.out
         home.value now /home/pme///////////'
         home.value now /home/pme'
         %
     
     With the cout statement uncommented, this also does the
     expected thing.  So this bug is fixed in current
     development sources.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1710&database=gcc
>From george@moberg.com Sun Apr 01 00:00:00 2001
From: george@moberg.com
To: libstdc++-gnats@sourceware.cygnus.com
Subject: libstdc++/1858: -fcheck-memory-usage cannot be used with basic_string<>
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20000310214844.14302.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00882.html
Content-length: 1572

>Number:         1858
>Category:       libstdc++
>Synopsis:       -fcheck-memory-usage cannot be used with basic_string<>
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 03 09:26:07 PST 2001
>Closed-Date:    
>Last-Modified:  
>Originator:     george@moberg.com
>Release:        The version that's included with gcc 2.95.2.
>Organization:
>Environment:
Linux Mandrake 7.0 on an Intel Pentium II.
>Description:
The basic_string<> class uses asm() in its release() method
for the Rep structure.  This causes a compilation error
when compiling with the GCC -fcheck-memory-usage option.
>How-To-Repeat:
Compile the above program with the option -fcheck-memory-usage.
>Fix:
I could discover no easy workaround.  I would assume that
it would be possible to move the asm() statement in this
function to another file and mark that with
__attribute__ ((no_check_memory_usage)), but I don't know
anything about x86 assembly language.

iostream.h and stl_alloc.h also have assembly language in them.
>Release-Note:
>Audit-Trail:

Formerly PR libstdc++/41

>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="str.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="str.cc"

I2luY2x1ZGUgPHN0cmluZz4KI2luY2x1ZGUgPGlvc3RyZWFtPgoKaW50IG1haW4oaW50IGFyZ2Ms
IGNoYXIgKmFyZ3ZbXSkKewoJc3RyaW5nCXRoZXJlKCJ0aGVyZSEiKTsKCgljb3V0IDw8ICJIZWxs
byAiIDw8IHRoZXJlIDw8IGVuZGw7CgoJcmV0dXJuIDA7Cn0K


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-04-01  0:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-01  0:00 libstdc++/1710 James Dennett
2001-04-01  0:00 libstdc++/1710 pme

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).