Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Jason Merrill]

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

> sin__g1Zd_RCcomplex_complex         /var/tmp/cca005N51.o

Arrgh.  This is a bug in the mangling code; that should be __F1Z, not
__g1Z.  However, I don't understand why it's failing; it seems to be a
miscompilation of build_decl_overload_real.  Does this patch fix
the problem?

Tue Sep 30 08:51:36 1997  Jason Merrill  <jason@yorick.cygnus.com>

        * method.c (build_decl_overload_real): Reformat.

Index: method.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/cp/method.c,v
retrieving revision 1.158
retrieving revision 1.159
diff -c -r1.158 -r1.159
*** method.c	1997/09/30 07:20:51	1.158
--- method.c	1997/09/30 15:54:09	1.159
***************
*** 1157,1164 ****
  				  TREE_CHAIN (parms));
        }
      }
    else
!     OB_PUTC ((tparms != NULL_TREE) ? 'H' : 'F');
  
    if (tparms)
      {
--- 1157,1166 ----
  				  TREE_CHAIN (parms));
        }
      }
+   else if (tparms)
+     OB_PUTC ('H');
    else
!     OB_PUTC ('F');
  
    if (tparms)
      {

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Torbjorn Lindgren]

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

On 1 Oct 1997, Jason Merrill wrote:

> >>>>> Joe Buck <jbuck@synopsys.com> writes:
> 
> > sin__g1Zd_RCcomplex_complex         /var/tmp/cca005N51.o
> 
> Arrgh.  This is a bug in the mangling code; that should be __F1Z, not
> __g1Z.  However, I don't understand why it's failing; it seems to be a
> miscompilation of build_decl_overload_real.  Does this patch fix
> the problem?
> 
> Tue Sep 30 08:51:36 1997  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * method.c (build_decl_overload_real): Reformat.
> 
> Index: method.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gcc/cp/method.c,v
> retrieving revision 1.158
> retrieving revision 1.159
> diff -c -r1.158 -r1.159
> *** method.c	1997/09/30 07:20:51	1.158
> --- method.c	1997/09/30 15:54:09	1.159
> ***************
> *** 1157,1164 ****
>   				  TREE_CHAIN (parms));
>         }
>       }
>     else
> !     OB_PUTC ((tparms != NULL_TREE) ? 'H' : 'F');
>   
>     if (tparms)
>       {
> --- 1157,1166 ----
>   				  TREE_CHAIN (parms));
>         }
>       }
> +   else if (tparms)
> +     OB_PUTC ('H');
>     else
> !     OB_PUTC ('F');
>   
>     if (tparms)
>       {
> 

-- 
Torbjörn Lindgren
Karenlyst Allè 5, N-0277 Oslo, Norway     Phone: +47 22420102
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.

Re: 970929 test results: libstdc++ test failures!

[Torbjorn Lindgren]

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

Oops. Sorry about the earlier copy that were sent by accident, I tried to
tell Pine to drop it so I could check it out fully first...


On 1 Oct 1997, Jason Merrill wrote:
> > sin__g1Zd_RCcomplex_complex         /var/tmp/cca005N51.o
> 
> Arrgh.  This is a bug in the mangling code; that should be __F1Z, not
> __g1Z.  However, I don't understand why it's failing; it seems to be a
> miscompilation of build_decl_overload_real.  Does this patch fix
> the problem?

When I first tried running egcs 970929 on IRIX 6.2 I had bad problems with
name mangling, it didn't find all the functions when it tried to link.
(The first program I tried to compile with egcs-970929 was DDD 2.1.1)

After I recompiled egcs with this patch (and Thomas Koenig's reload.c
(decompose) patch) the same compile of DDD worked fine, it compiled and
linked fine....

Note: The first time I used "make bootstrap CFLAGS=-O2", and the second
time I just used "make bootstrap", both times on a clean copy of egcs.
I doubt that was the reason for the change, but I thought I should mention
all the possible relevant fact.

> Tue Sep 30 08:51:36 1997  Jason Merrill  <jason@yorick.cygnus.com>
>
>         * method.c (build_decl_overload_real): Reformat.

-- 
Torbjörn Lindgren
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

Jason writes:

> Arrgh.  This is a bug in the mangling code; that should be __F1Z, not
> __g1Z.  However, I don't understand why it's failing; it seems to be a
> miscompilation of build_decl_overload_real.  Does this patch fix
> the problem?

No, in fact, with this patch, *all* the libstdc++ tests fail to compile.

Patch is below.

> Tue Sep 30 08:51:36 1997  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * method.c (build_decl_overload_real): Reformat.
> 
> Index: method.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gcc/cp/method.c,v
> retrieving revision 1.158
> retrieving revision 1.159
> diff -c -r1.158 -r1.159
> *** method.c	1997/09/30 07:20:51	1.158
> --- method.c	1997/09/30 15:54:09	1.159
> ***************
> *** 1157,1164 ****
>   				  TREE_CHAIN (parms));
>         }
>       }
>     else
> !     OB_PUTC ((tparms != NULL_TREE) ? 'H' : 'F');
>   
>     if (tparms)
>       {
> --- 1157,1166 ----
>   				  TREE_CHAIN (parms));
>         }
>       }
> +   else if (tparms)
> +     OB_PUTC ('H');
>     else
> !     OB_PUTC ('F');
>   
>     if (tparms)
>       {
> 

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Jason Merrill]

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

> Jason writes:
>> Arrgh.  This is a bug in the mangling code; that should be __F1Z, not
>> __g1Z.  However, I don't understand why it's failing; it seems to be a
>> miscompilation of build_decl_overload_real.  Does this patch fix
>> the problem?

> No, in fact, with this patch, *all* the libstdc++ tests fail to compile.

Arrgh again.  That patch seems to work for other folks.  Did you rebuild
all the library code, including libgcc?  If so, could you possibly
investigate why that section of build_decl_overload_real is doing the wrong
thing?  It seems like an awfully simple operation to me.  I don't know why
it's breaking all of a sudden.

Jason

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Chip Salzenberg]

I'm using a Linux system with glibc 2.0.4.  Despite Ulrich's patches
that are a part of egcs-970929, a simple program to write to cout
dumps core.  I really don't know what to do next.
-- 
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

> > No, in fact, with this patch, *all* the libstdc++ tests fail to compile.
> 
> Arrgh again.  That patch seems to work for other folks.  Did you rebuild
> all the library code, including libgcc?

No, I didn't (silly me, just re-ran the tests).  I'll try blowing
everything away first and build again.

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[H.J. Lu]

> 
> I'm using a Linux system with glibc 2.0.4.  Despite Ulrich's patches
> that are a part of egcs-970929, a simple program to write to cout
> dumps core.  I really don't know what to do next.

You need glibc 2.0.5c and a patch for linuxthreads enclosed here.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)
--- linuxthreads/sysdeps/pthread/libc-lock.h.orig	Thu Oct  2 13:20:38 1997
+++ linuxthreads/sysdeps/pthread/libc-lock.h	Thu Oct  2 13:22:24 1997
@@ -166,6 +166,11 @@
 /* We need portable names for some functions.  E.g., when they are
    used as argument to __libc_cleanup_region_start.  */
 # define __libc_mutex_unlock __pthread_mutex_unlock
+#else
+# ifdef __ELF__
+#  pragma weak _pthread_cleanup_push_defer
+#  pragma weak _pthread_cleanup_pop_restore
+# endif
 #endif
 
 #endif	/* bits/libc-lock.h */

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Chip Salzenberg]

According to H.J. Lu:
> > I'm using a Linux system with glibc 2.0.4.  Despite Ulrich's patches
> > that are a part of egcs-970929, a simple program to write to cout
> > dumps core.  I really don't know what to do next.
> 
> You need glibc 2.0.5c and a patch for linuxthreads enclosed here.

Is 2.0.4 beyond help?  Debian doesn't have a 2.0.5 package yet, and
when I looked at compiling 2.0.5c it seemed likely that I would get
something wrong.
-- 
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[H.J. Lu]

> 
> According to H.J. Lu:
> > > I'm using a Linux system with glibc 2.0.4.  Despite Ulrich's patches
> > > that are a part of egcs-970929, a simple program to write to cout
> > > dumps core.  I really don't know what to do next.
> > 
> > You need glibc 2.0.5c and a patch for linuxthreads enclosed here.
> 
> Is 2.0.4 beyond help?  Debian doesn't have a 2.0.5 package yet, and
> when I looked at compiling 2.0.5c it seemed likely that I would get
> something wrong.

libio in egcs use thunks. You need 2.0.5c for that.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

> According to H.J. Lu:
> > > I'm using a Linux system with glibc 2.0.4.  Despite Ulrich's patches
> > > that are a part of egcs-970929, a simple program to write to cout
> > > dumps core.  I really don't know what to do next.
> > 
> > You need glibc 2.0.5c and a patch for linuxthreads enclosed here.
> 
> Is 2.0.4 beyond help?  Debian doesn't have a 2.0.5 package yet, and
> when I looked at compiling 2.0.5c it seemed likely that I would get
> something wrong.

I want to get out of the mode where I have to continually replace my Linux
C libraries to use a new compiler.  I don't have to do that on any other
platform.  What's worse, the new libraries often break existing
applications, ones I may not have the source for (e.g. Netscape), and
pointing the finger at the other app developer does no good.  Why should
this be acceptable for Linux?  It basically says that only wizards may
use new compilers, or else all Linux users must wait for a wizard, such
as HJ Lu, to build binaries for everyone.  This makes Linux feel, um,
"proprietary".  As Mike Tiemann once said, free software is supposed to
be no-hassle software.

It would be better if the new compiler can adapt to the existing
libraries, possibly by adding more autoconf tests to find problem areas.

When egcs is released, it should be possible for Linux users who have the
then-current Red Hat or Debian distribution to build a working egcs
without upgrading their C library.

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[H.J. Lu]

> I want to get out of the mode where I have to continually replace my Linux
> C libraries to use a new compiler.  I don't have to do that on any other

That is not entirely true. I used to have a patch to support it.

> platform.  What's worse, the new libraries often break existing
> applications, ones I may not have the source for (e.g. Netscape), and

It shouldn't break Netscape unless it is a bug in Netscape itself.
The new libc may expose the bug. As far as I know, the new Netscape
works ok.

> pointing the finger at the other app developer does no good.  Why should
> this be acceptable for Linux?  It basically says that only wizards may
> use new compilers, or else all Linux users must wait for a wizard, such
> as HJ Lu, to build binaries for everyone.  This makes Linux feel, um,
> "proprietary".  As Mike Tiemann once said, free software is supposed to
> be no-hassle software.

The problem is not with gcc. It is libio that causes the problem.
The solution has been there for a long time. But no one cared
enough to make the official libg++ to work with linux out of box.
Now Ulrich is working on libg++. Things will be different. 

> 
> It would be better if the new compiler can adapt to the existing
> libraries, possibly by adding more autoconf tests to find problem areas.
> 
> When egcs is released, it should be possible for Linux users who have the
> then-current Red Hat or Debian distribution to build a working egcs
> without upgrading their C library.
> 

The new C libraries usually fix some bugs. It makes senses to
upgrade libc first.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

I wrote:	
> > No, in fact, with this patch, *all* the libstdc++ tests fail to compile.

Jason writes: 
> Arrgh again.  That patch seems to work for other folks.  Did you rebuild
> all the library code, including libgcc?

Joy.  After blowing everything away and rebuilding, Jason's patch fixes
the libstdc++ tests (they all pass again).

I'm re-running the g++ tests now to see if anything changes.

Re: 970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

I wrote:

[ after Jason's patch to method.c: ]
> I'm re-running the g++ tests now to see if anything changes.

Yep, a definite improvement.  Before Jason's patch, on sun-solaris I got

FAIL: g++.brendan/arm3.C previous declaration (test for errors, line 7)
FAIL: g++.brendan/arm3.C previously declared (test for errors, line 9)
FAIL: g++.brendan/template9.C (test for excess errors)
FAIL: g++.jason/template31.C (test for excess errors)
FAIL: g++.jason/template38.C (test for excess errors)
FAIL: g++.law/arg7.C (test for excess errors)
FAIL: g++.law/missed-error2.C extern (test for errors, line 20)

After the patch, I get

FAIL: g++.jason/template31.C (test for excess errors)
FAIL: g++.law/missed-error2.C extern (test for errors, line 20)

Very impressive indeed!

970929 test results: libstdc++ test failures! (sparc-solaris251)

[Joe Buck]

Here are results for 970929 on sparc-sun-solaris2.5.1.
What's new are teh libstdc++ failures, which are link problems.

The demangler doesn't recognize these symbols.  Is this related to the
new treatment of template functions mentioned earlier?

For tcomplex:
Undefined			first referenced
 symbol  			    in file
sin__g1Zd_RCcomplex_complex         /var/tmp/cca005N51.o
__dv__l1Zd_RCcomplexT0_complex      /var/tmp/cca005N51.o
cos__g1Zd_RCcomplex_complex         /var/tmp/cca005N51.o
sqrt__l1Zd_RCcomplex_complex        /var/tmp/cca005N51.o
__rs__11Zd_R7istreamRcomplex_R7istream /var/tmp/cca005N51.o
__ls__l1Zd_R7ostreamRCcomplex_R7ostream /var/tmp/cca005N51.o

For tstring:

Undefined			first referenced
 symbol  			    in file
__rs___2ZcZt18string_char_traits1Zc_R7istreamRbasic_string_R7istream /var/tmp/cca005Pq1.o
__ls__b2ZcZt18string_char_traits1Zc_R7ostreamRCbasic_string_R7ostream /var/tmp/cca005Pq1.o

Here are the rest of the results.
--------------------------------------------------------------------
gcc results:

FAIL: gcc.c-torture/compile/961203-1.c,  -O0  
FAIL: gcc.c-torture/compile/961203-1.c,  -O1  
FAIL: gcc.c-torture/compile/961203-1.c,  -O2  
FAIL: gcc.c-torture/compile/961203-1.c,  -O2 -fomit-frame-pointer -finline-functions  
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
FAIL: gcc.c-torture/execute/loop-2f.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 

		=== gcc Summary ===

# of expected passes		4881
# of unexpected failures	8
# of expected failures		4
# of unsupported tests		6

g++ results:

FAIL: g++.brendan/arm3.C previous declaration (test for errors, line 7)
FAIL: g++.brendan/arm3.C previously declared (test for errors, line 9)
FAIL: g++.brendan/template9.C (test for excess errors)
FAIL: g++.jason/template31.C (test for excess errors)
FAIL: g++.jason/template38.C (test for excess errors)
FAIL: g++.law/arg7.C (test for excess errors)
FAIL: g++.law/missed-error2.C extern (test for errors, line 20)

		=== g++ Summary ===

# of expected passes		3368
# of unexpected failures	7
# of expected failures		83
# of untested testcases		6

libstdc++ results:

Using ./config/default.exp as tool-and-target-specific interface file.
FAIL: tcomplex.cc compilation
FAIL: tcomplex.cc -O compilation
FAIL: tstring.cc compilation
FAIL: tstring.cc -O compilation

		=== libstdc++ Summary ===

# of expected passes		18
# of unexpected failures	4
# of expected failures		8

libio results:

		=== libio Summary ===

# of expected passes		40