install

install

[Peter Garner]

Dear Folks,

  Thank you very much for egcs.  I have just downloaded and installed
the latest version of egcs.  I followed the instructions on your web
page, and I believe the installation went flawlessly.  Unfortunately
I did not notice your request to mail you the output from running
srcdir/config.guess UNTIL AFTER I had deleted srcdir!  I am very
sorry about that.

  I wonder if I can ask you a question?  I was under the impression
that this was an ANSI/ISO C++ compiler.  Yet I wrote a small test
program that simply allocates more memory with the new [] operator
than the system can possibly allocate.  This program aborts with an
error message stating something to the effect that an attempt to
allocate virtual memory faild.  Of course the ISO/ANSI behaviour is
to throw an exception of type bad_alloc in this case.  Have I done
something wrong or failed to enable something?  Will using the latest
libg++ (libg++-2.8.1-980415.tar.gz) rectify this?

Thank you VERY much

Peter Garner

Re: install

[Martin von Loewis]

Peter,

> Unfortunately
> I did not notice your request to mail you the output from running
> srcdir/config.guess UNTIL AFTER I had deleted srcdir!  I am very
> sorry about that.

Don't worry about that. I assume it was egcs 1.0.2 which you've
installed. There are many reports on successful installation coming in
each day, so it is pretty certain that egcs 1.0 works in the field :-)
Reports on failures are more interesting.

>   I wonder if I can ask you a question?  I was under the impression
> that this was an ANSI/ISO C++ compiler.  Yet I wrote a small test
> program that simply allocates more memory with the new [] operator
> than the system can possibly allocate.  This program aborts with an
> error message stating something to the effect that an attempt to
> allocate virtual memory faild.

Could you report this as a bug to egcs-bugs? Please include all the
relevant information, such as what system you use and what compiler,
and what your testcase is. I tried compiling

#include <new>
#include <iostream.h>

main()
try{
  char *s = new char[1<<28];
}catch(std::bad_alloc)
{
  cerr<<"Caught oom"<<endl;
}

with egcs-2.91.16 (which is a development snapshot) on Linux, and
I get the message 'Caught oom'.

Regards,
Martin

Re: install

[Stefan Meixner]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

Hi Martin,
out of curiosity I tried your testcase with

Reading specs from /usr/lib/gcc-lib/i486-pc-linux-gnulibc1/egcs-2.91.22/specs
gcc version egcs-2.91.22 980404 (gcc2 ss-980401 experimental)

Reading specs from /usr/lib/gcc-lib/i486-pc-linux-gnulibc1/egcs-2.91.08/specs
gcc version egcs-2.91.08 980214 (gcc-2.8.0 release)

because I usually do not use exception handling.

> 
> Could you report this as a bug to egcs-bugs? Please include all the
> relevant information, such as what system you use and what compiler,
> and what your testcase is. I tried compiling
> 
> #include <new>
> #include <iostream.h>
> 
> main()
> try{
>   char *s = new char[1<<28];
> }catch(std::bad_alloc)
> {
>   cerr<<"Caught oom"<<endl;
> }
> 
> with egcs-2.91.16 (which is a development snapshot) on Linux, and
> I get the message 'Caught oom'.
> 
> Regards,
> Martin
> 

But I get the following incorrect result:
´Virtual memory exceeded in `new'´

System is:
KERNEL:
Linux 2.1.97 i486 unknown
AS:       
GNU assembler 2.9
LD:       
GNU ld version 2.9 (with BFD 2.9.0.3)
LIBC:     
/lib/libc.so.4 -> libc.so.4.7.5*
/lib/libc.so.5 -> libc.so.5.4.44*
LDD:      
ldd: version 1.9.6
LIBG++:   
/usr/lib/libg++.so.2.8 -> libg++.so.2.8.1*

Stefan

bad_alloc exceptions on Linux (Was: Re: install)

[Martin von Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

> But I get the following incorrect result:
> ´Virtual memory exceeded in `new'´
> 
> System is:
> LIBC:     
> /lib/libc.so.4 -> libc.so.4.7.5*
> /lib/libc.so.5 -> libc.so.5.4.44*

I see. This must be a well-known problem, at least to the authors of
libc 5. If you do nm(1) on libc 5, you'll find it implements
__builtin_new. It looks like this copy of __builtin_new is being used,
instead of the copy in egcs (which produces an exception instead of a
message).

This raise some questions:
1. Is this a known problem? Why was __builtin_new included into libc
   in the first place?
2. Why isn't the copy of __builtin_new of cp/new1.cc being used?
   Ah, I see: __builtin_new is not weak. Is this the problem?

So, in short: you won't get bad_alloc exceptions with libc 5, unless
somebody renames __builtin_new (and friends).

I personally use glibc 2 (aka libc 6), and it works just fine.

Martin

Re: bad_alloc exceptions on Linux (Was: Re: install)

[H.J. Lu]

> 
> > But I get the following incorrect result:
> > =B4Virtual memory exceeded in `new'=B4
> >=20
> > System is:
> > LIBC:    =20
> > /lib/libc.so.4 -> libc.so.4.7.5*
> > /lib/libc.so.5 -> libc.so.5.4.44*
> 
> I see. This must be a well-known problem, at least to the authors of
> libc 5. If you do nm(1) on libc 5, you'll find it implements
> __builtin_new. It looks like this copy of __builtin_new is being used,
> instead of the copy in egcs (which produces an exception instead of a
> message).
> 
> This raise some questions:
> 1. Is this a known problem? Why was __builtin_new included into libc
>    in the first place?

The stdio in the Linux C library is based on libio, which was written
in C++ when it was first used in Linux.

> 2. Why isn't the copy of __builtin_new of cp/new1.cc being used?
>    Ah, I see: __builtin_new is not weak. Is this the problem?
> 
> So, in short: you won't get bad_alloc exceptions with libc 5, unless
> somebody renames __builtin_new (and friends).
> 
> I personally use glibc 2 (aka libc 6), and it works just fine.
> 

Here is a patch for libc 5.4.44. I don't know if it works or not.


-- 
H.J. Lu (hjl@gnu.org)
---
Index: gcc/libgcc2.c
===================================================================
RCS file: /home/work/cvs/linux/libc/gcc/libgcc2.c,v
retrieving revision 1.3
diff -u -r1.3 libgcc2.c
--- libgcc2.c	1995/09/11 02:26:27	1.3
+++ libgcc2.c	1998/04/23 03:57:09
@@ -402,6 +402,8 @@
   8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,8,
 };
 
+#pragma weak __udivmoddi4
+
 #if (defined (L_udivdi3) || defined (L_divdi3) || \
      defined (L_umoddi3) || defined (L_moddi3))
 static inline
@@ -683,6 +685,8 @@
 #endif
 
 #ifdef L_umoddi3
+#pragma weak __umoddi3
+
 UDItype __udivmoddi4 ();
 UDItype
 __umoddi3 (u, v)
@@ -697,6 +701,8 @@
 #endif
 
 #ifdef L_udivdi3
+#pragma weak __udivdi3
+
 UDItype __udivmoddi4 ();
 UDItype
 __udivdi3 (n, d)
@@ -1141,6 +1147,8 @@
 \f
 #ifdef L__gcc_bcmp
 
+#pragma weak __gcc_bcmp
+
 /* Like bcmp except the sign is meaningful.
    Reult is negative if S1 is less than S2,
    positive if S1 is greater, 0 if S1 and S2 are equal.  */
@@ -1163,6 +1171,9 @@
 #endif
 \f\f
 #ifdef L_varargs
+
+#pragma weak __builtin_saveregs
+
 #ifdef __i860__
 #if defined(__svr4__) || defined(__alliant__)
 	asm ("	.text");
@@ -1616,6 +1627,7 @@
 typedef void (*vfp)(void);
 extern vfp __new_handler;
 extern void __default_new_handler (void);
+#pragma weak __builtin_new
 
 void *
 __builtin_new (size_t sz)
@@ -1642,6 +1654,7 @@
    is used by C++ programs to allocate a block of memory for an array.  */
 
 extern void * __builtin_new (size_t);
+#pragma weak __builtin_vec_new
 
 void *
 __builtin_vec_new (size_t sz)
@@ -1670,8 +1683,12 @@
 typedef void (*vfp)(void);
 void __default_new_handler (void);
 
+#pragma weak __new_handler
+
 vfp __new_handler = (vfp)0;
 
+#pragma weak set_new_handler
+
 vfp
 set_new_handler (vfp handler)
 {
@@ -1685,6 +1702,8 @@
 
 #define MESSAGE "Virtual memory exceeded in `new'\n"
 
+#pragma weak __default_new_handler
+
 void
 __default_new_handler ()
 {
@@ -1705,6 +1724,8 @@
    by C++ programs to return to the free store a block of memory allocated
    as a single object. */
 
+#pragma weak __builtin_delete
+
 void
 __builtin_delete (void *ptr)
 {
@@ -1719,6 +1740,7 @@
    allocated as an array. */
 
 extern void __builtin_delete (void *);
+#pragma weak __builtin_vec_delete
 
 void
 __builtin_vec_delete (void *ptr)
@@ -1730,6 +1752,8 @@
 /* End of C++ free-store management functions */
 \f
 #ifdef L_shtab
+#pragma weak __shtab
+
 unsigned int __shtab[] = {
     0x00000001, 0x00000002, 0x00000004, 0x00000008,
     0x00000010, 0x00000020, 0x00000040, 0x00000080,
@@ -1747,6 +1771,8 @@
 
 #define INSN_CACHE_PLANE_SIZE (INSN_CACHE_SIZE / INSN_CACHE_DEPTH)
 
+#pragma weak __clear_cache
+
 void
 __clear_cache (beg, end)
      char *beg, *end;
@@ -2178,6 +2204,8 @@
  */
 
 
+#pragma weak __find_first_exception_table_match
+
 void *
 __find_first_exception_table_match(pc)
 void *pc;
@@ -2235,6 +2263,8 @@
   return (void*)0;
 }
 
+#pragma weak __throw_type_match
+
 void *
 __throw_type_match (void *catch_type, void *throw_type, void* obj)
 {
@@ -2247,6 +2277,8 @@
  return 0;
 }
 
+#pragma weak __register_exceptions
+
 void
 __register_exceptions (exception_table *table)
 {
@@ -2276,7 +2308,10 @@
   exception_table_list = node;
 }
 
+#pragma weak __unwind_function
+
 #if #machine(i386)
+
 void
 __unwind_function(void *ptr)
 {
@@ -2353,6 +2388,8 @@
 #endif /* inhibit_libc */
 
 #define MESSAGE "pure virtual method called\n"
+
+#pragma weak __pure_virtual
 
 void
 __pure_virtual ()

Re: bad_alloc exceptions on Linux (Was: Re: install)

[Stefan Meixner]

> 
> Here is a patch for libc 5.4.44. I don't know if it works or not.
> 
> 
> -- 
> H.J. Lu (hjl@gnu.org)
> ---

thanks a lot, bad_alloc seem to work for me now. 
I had a few problem compiling libc 5.4.44 though with
gcc version egcs-2.91.22 980404 (gcc2 ss-980401 experimental).
I managned to compile the whole library by compiling the problematic
files without optimization. The problems were

printf_fp.c:947: Unable to find a register to spill.
erfl.c:311: Unable to find a register to spill.
j0l.c:192: Unable to find a register to spill.
j1l.c:195: Unable to find a register to spill.
powl.c:76: Unable to find a register to spill.

Now my system seems to work mostly stable. telnet does not work anymore.
So I would like to ask you to make libc 5.4.45 with your
patch applied.

It seems to solve the bad_alloc problems with libc5.

Thanks!

Stefan

Re: bad_alloc exceptions on Linux (Was: Re: install)

[Prasong Aroonruviwat]

On Thu, 23 Apr 1998, Stefan Meixner wrote:

> > 
...
...
...
> Now my system seems to work mostly stable. telnet does not work anymore.

        Happen to me too, I use the latest egcs in CVS tree to compile
    glibc 2.0.7 everything is ok except I can't use telnet (maybe more than
    this but I still don't know it).

        And I can't compile many program with an optimization... -O0 is work.
    for example. bison-1.25, perl-5.004_64, XFree86-6.3...

        It's work with egcs-19980418...

Regards,
psa

> So I would like to ask you to make libc 5.4.45 with your
> patch applied.
> 
> It seems to solve the bad_alloc problems with libc5.
> 
> Thanks!
> 
> Stefan
> 

+---------------------------------------------------------------------------+
| ._  ._  _.  _  _  ._   _       _. ._  _   _  ._  ._        o       _. _|_ |
| |_) |  (_| _> (_) | | (_|     (_| |  (_) (_) | | |  |_| \/ | \/\/ (_|  |_ |
| |                      _|                                                 |
+---------------------------------------------------------------------------+
I talk to God but the sky is empty...
                                                              Sylvia Plath...

Re: bad_alloc exceptions on Linux (Was: Re: install)

[H.J. Lu]

> 
> On Thu, 23 Apr 1998, Stefan Meixner wrote:
> 
> > > 
> ...
> ...
> ...
> > Now my system seems to work mostly stable. telnet does not work anymore.
> 
>         Happen to me too, I use the latest egcs in CVS tree to compile
>     glibc 2.0.7 everything is ok except I can't use telnet (maybe more than
>     this but I still don't know it).
> 
>         And I can't compile many program with an optimization... -O0 is work.
>     for example. bison-1.25, perl-5.004_64, XFree86-6.3...
> 

I compiled my linux kernel 2.1.97 with egcs 980418 by accident. The
SCSI driver and/or fs code are miscompiled. I got all kinds of error.
It took me 5 minutes to realise what happened. I went back to egcs
1.0.3. The new kernel worked fine.

H.J.

Re: bad_alloc exceptions on Linux (Was: Re: install)

[Stefan Meixner]

> > 
> >         Happen to me too, I use the latest egcs in CVS tree to compile
> >     glibc 2.0.7 everything is ok except I can't use telnet (maybe more than
> >     this but I still don't know it).
> > 
> >         And I can't compile many program with an optimization... -O0 is work.
> >     for example. bison-1.25, perl-5.004_64, XFree86-6.3...
> > 
> 
> I compiled my linux kernel 2.1.97 with egcs 980418 by accident. The
> SCSI driver and/or fs code are miscompiled. I got all kinds of error.
> It took me 5 minutes to realise what happened. I went back to egcs
> 1.0.3. The new kernel worked fine.
> 
> H.J.
> 

I am not using egcs-19980418, but egcs-2.91.22 980404. I tested egcs-19980418
and even the testsuite had a couple of errors. But egcs-2.91.22 980404 seems
to work rather well for me. I am running a linux 2.1.97 kernel compiled with
egcs-2.91.22 980404 here. 
And I need the C++ enhancements in the development branch for my project. So 
I like to stress that usings a development compiler, if you carefully choose
the right snapshot, is not a bad thing.

Regards.

Stefan

Re: bad_alloc exceptions on Linux (Was: Re: install)

[Jim Wilson]

	printf_fp.c:947: Unable to find a register to spill.

If these were all XFmode related problems, then they should all be gone
with the next snapshot.  The patch fixing this was checked in early this
week.

Jim

Re: install

[David Lucas]

> Could you report this as a bug to egcs-bugs? Please include all the
> relevant information, such as what system you use and what compiler,
> and what your testcase is. I tried compiling
> 
> #include <new>
> #include <iostream.h>
> 
> main()
> try{
>   char *s = new char[1<<28];
> }catch(std::bad_alloc)
> {
>   cerr<<"Caught oom"<<endl;
> }
> 
> with egcs-2.91.16 (which is a development snapshot) on Linux, and
> I get the message 'Caught oom'.
> 
> Regards,
> Martin

I tried it and it failed on HP-UX too...

GNU assembler version 2.7 (hppa1.1-hp-hpux10.20), using BFD version 2.7
% g++ --version
egcs-2.91.22

(gdb) where
#0  0x7ae90124 in __builtin_new (sz=0)
#1  0x7ffffffc in ?? ()
#2  0xdd74 in __sjthrow ()
#3  0x0 in ?? ()

Hope the info helps...

Later,
Dave

-- 
-----------------------------------------------------------------
David Lucas                    |  mailto:dlucas@checkfree.com
Staff Software Engineer        |                                  
Systems Software Development   |  My opinions are IMHO.
OFX Server Devl 08-126         |                                  
                               |
CheckFree Corporation          |  Work#  614.825.3511            
8275 High Street               |  Fax#   614.825.3104            
Columbus, OH 43235             |  http://www.checkfree.com
-----------------------------------------------------------------

Re: install

[Kriang Lerdsuwanakij]

Peter Garner wrote:
> Yet I wrote a small test
> program that simply allocates more memory with the new [] operator
> than the system can possibly allocate.  This program aborts with an
> error message stating something to the effect that an attempt to
> allocate virtual memory faild.  Of course the ISO/ANSI behaviour is
> to throw an exception of type bad_alloc in this case.  Have I done
> something wrong or failed to enable something?  

I guess you are using egcs 1.0.2.  For egcs 1.0.x, the behavior when new
cannot allocate memory is displaying memory exhaust error and abort. 
For latest egcs snapshot, bad_alloc is thrown.

With egcs 1.0.x, you can get the desired behavior by using
set_new_handler and throwing an exception inside your new handler. 
However it does not always work as exception handling code needs some
free memory to operate which is also true for the latest egcs snapshot.
For more info, see http://www.cygnus.com/ml/egcs/1998-Mar/0320.html

> Will using the latest libg++ (libg++-2.8.1-980415.tar.gz) rectify
> this?
No.

--Kriang