Results for g++ 3.1 application testing on i686-pc-linux-gnu

Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Peter Schmid]

I tested g++ 3.1 20020302 versus some applications:

Here are the results:

current boost cvs:
All tests pass. g++ does not provide the zero sized base class
optimization. Therefore, there are seven "failures" for empty_* types in
object_type_traits_test.cpp.

blitz-20001213:
Compiling wei-ku-1.cpp crashes the compiler when
optimization is on. Cf. PR c++/5504 (gcc 3.0 regression).

root_v3.02.07:
Everything works, except for test/bench.cxx, as for gcc 3.0.

pooma-gcc:
No problems detected. All tests pass.

Code from Josuttis' Book "The C++ Standard Library":

Everything works fine, except for the parsing of doubles on input when
the locale is set to de_DE (PR libstdc++/5816, grouping related) and
the unresolved state of PR libstc++/5133.

stepanov_v1p2.C:

-O
Abstraction Penalty: 1.14
-O2
Abstraction Penalty: 1.30
-O3
Abstraction Penalty: 1.30
-O2  -finline-limit=10000
Abstraction Penalty: 1.30
-O2  -finline-limit=100000
Abstraction Penalty: 1.30

mtl-2.1.2-20:
No problems detected, after applying patches for missing typename
warnings.

STLport-4.5.3
No problems detected. All tests pass.

System setup:
SuSE 7.3
Glibc 2.2.4 + patches
Linux 2.4.17
binutils version 2.11.93.0.2
g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.1 20020302 (prerelease)

Hope this helps,

Peter Schmid

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Craig Rodrigues]

On Mon, Mar 04, 2002 at 04:44:18AM +0100, Peter Schmid wrote:
> I tested g++ 3.1 20020302 versus some applications:
> 
> Here are the results:
> 
> current boost cvs:

Hi,

I have a bunch of patches pending for Boost:
http://groups.yahoo.com/group/boost/message/26492
http://groups.yahoo.com/group/boost/message/26466
http://groups.yahoo.com/group/boost/message/26463
http://groups.yahoo.com/group/boost/message/26462
http://groups.yahoo.com/group/boost/message/26457

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@attbi.com

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

Has anybody tried KDE 3.0?

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Stephen M.Webb]

On March 4, 2002 02:51 am, Benjamin Kosnik wrote:
> Has anybody tried KDE 3.0?

I haven't gotten as far as KDE yet, but Qt 3.0.2 builds and runs with 
no problems at all.  I'll be starting on KDE today.

-- 
Stephen M. Webb

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

> I haven't gotten as far as KDE yet, but Qt 3.0.2 builds and runs with 
> no problems at all.  I'll be starting on KDE today.

Great news! Thanks Stephen.

-benjamin

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

> binutils version 2.11.93.0.2

Ack! I just noticed this.

Peter, is there anyway you can try this with a newer binutils? Or, the
next time you do this, update to new binutils? This version won't version
the C++ library. Updating to mainline or the 2.12 branch would turn it on
by default, no additional flags required. 

The versioning is important in application testing because we are trying 
to make sure that all necessary symbols are exported. 

-benjamin

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Craig Rodrigues]

Hi,

I just tested the latest Boost from CVS, after
they incorporated my fixes:
http://home.attbi.com/~rodrigc/boost/cs-linux.html

Not bad, only one failure.

There are still some problems elsewhere in Boost,
but at least a lot of the regression tests pass.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@attbi.com

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Stephen M. Webb]

On March 4, 2002 08:58 am, Stephen M.Webb wrote:
> On March 4, 2002 02:51 am, Benjamin Kosnik wrote:
> > Has anybody tried KDE 3.0?
>
> I haven't gotten as far as KDE yet, but Qt 3.0.2 builds and runs with
> no problems at all.  I'll be starting on KDE today.

Well' I've run into some problems with KDE.

First off, for internal reasons, I had to rebuild Qt 3.0.2, and it 
failed at runtime in its third party zlib library. I rebuilt using my 
system's zlib and everything works okay.  Don't know if the problem was 
in Qt or gcc, but I can't go without Qt for very long so I can't look 
further.

Here's the big problem.  Building the libs package of KDE fails on 
vector<bool> with an unreferenced symbol error.  I've managed to 
isolate a small test case that reproduces the problem.

  #include <vector>

  int
  main(int, char*[])
  {
    std::vector<bool>::iterator i;
    ++i;
    return 0;
  }

The linker error is

  bv.o: In function `std::_Bit_iterator_base::_M_bump_up()':
  bv.o(.gnu.linkonce.t._ZNSt18_Bit_iterator_base10_M_bump_upEv+0x8):    
  undefined reference to `std::__WORD_BIT'
  collect2: ld returned 1 exit status

I checked the C++ library, and it's there, but not as an external 
symbol:

  stephen> nm -C /opt/gnu/lib/libstdc++.so.4 | grep WORD
  00054aa8 r std::__WORD_BIT

The symbol is defined in libstdc++-v3/src/stl-inst.cc.  All the other 
symbols defined there seem okay.  I can make the problem go away by 
forcing the linkage of __WORD_BIT to extern, but I'm not sure if that's 
the Right Thing To Do.  I'm not sure if this is a symbol versioning 
problem or a symbol linkage problem, so I'll leave it to the experts.

I'm using binutils 2.12.90 20020304.

There don't seem to be any test cases in the V3 testsuite that address 
vector<bool>

-- 
Stephen M. Webb

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Gabriel Dos Reis]

"Stephen M. Webb" <stephen.webb@bregmasoft.com> writes:

[...]

|   bv.o: In function `std::_Bit_iterator_base::_M_bump_up()':
|   bv.o(.gnu.linkonce.t._ZNSt18_Bit_iterator_base10_M_bump_upEv+0x8):    
|   undefined reference to `std::__WORD_BIT'

Sigh.  The right fix is to replace the declaration   

     extern const int __WORD_BIT;

in bits/stl_bvector.h with 

       const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));

and ditch that line in src/stl-inst.cc.

Patch pre-approved.

Best,

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

> Sigh.  The right fix is to replace the declaration   
> 
>      extern const int __WORD_BIT;
> 
> in bits/stl_bvector.h with 
> 
>        const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));
> 
> and ditch that line in src/stl-inst.cc.

Hmmm. I take issue with this.

I think the real, best solution would be to remove all these goofy global 
constants from the SGI STL, and put them in base classes where 
possible.......

If that's not always possible I suppose Gaby's suggestion is the 
next-best thing. It's annoying to me to see, for every header with

const int l = 5;

in it, this in every object file

00000000 r l

I know the GNU linker merges these, but still. Oh well.

-benjamin

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Gabriel Dos Reis]

Benjamin Kosnik <bkoz@redhat.com> writes:

| > Sigh.  The right fix is to replace the declaration   
| > 
| >      extern const int __WORD_BIT;
| > 
| > in bits/stl_bvector.h with 
| > 
| >        const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));
| > 
| > and ditch that line in src/stl-inst.cc.
| 
| Hmmm. I take issue with this.
| 
| I think the real, best solution would be to remove all these goofy global 
| constants from the SGI STL, and put them in base classes where 
| possible.......

Agreed.

| If that's not always possible I suppose Gaby's suggestion is the 
| next-best thing. It's annoying to me to see, for every header with
| 
| const int l = 5;
| 
| in it, this in every object file
| 
| 00000000 r l

Then, may I propose to turn __WORD_BIT into an enum so as to meet the
zero-overhead criterion.

-- Gaby

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

> Then, may I propose to turn __WORD_BIT into an enum so as to meet the
> zero-overhead criterion.

Sounds like the most elegant solution yet proposed. I'm all for it. 

These are the other problem children, from src/stl-inst.cc:

  const int __stl_threshold = 16;
  const int __stl_chunk_size = 7;
  const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));
  const _Rb_tree_Color_type _S_rb_tree_red = false;
  const _Rb_tree_Color_type _S_rb_tree_black = true;

-benjamin

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Richard Henderson]

On Tue, Mar 05, 2002 at 09:30:45PM +0100, Gabriel Dos Reis wrote:
>        const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));

Err, unsigned int, not unsigned long?


r~

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Richard Henderson]

On Tue, Mar 05, 2002 at 01:11:13PM -0800, Benjamin Kosnik wrote:
> It's annoying to me to see, for every header with
> 
> const int l = 5;
> 
> in it, this in every object file
> 
> 00000000 r l

I thought C++ allowed us to never emit these unless their 
address is taken?  If that's the case, I'd consider this
a (qoi) bug.


r~

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

> I thought C++ allowed us to never emit these unless their 
> address is taken?  If that's the case, I'd consider this
> a (qoi) bug.

Well, for "C" there is always making -fno-common the default, if it 
wasn't const...

:)

I'm not quite sure of C++ linkage rules for const ints. Jason's away, so 
perhaps somebody else can weigh in. To me, this seems to be clearly 
internal linkage, and thus able to be optimized.

From 3.5, linkage:

    * When a name has internal linkage, the entity it denotes can be 
referred to by names from other scopes in the same translation unit.

[...]

    * an object or reference that is explicitly declared const and 
neither explicitly declared extern nor previously declared to have 
external linkage; or

Perhaps I'm missing something. 

FWIW, icc also does this, but it's not in read-only...

00000000 d i

So, who knows. If there is no clear consensus on this from the 
compiler-folk within a couple days, I think the thing to do is make the 
source code changes to enums so that application testing can proceed.
 
-benjamin

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Tue, Mar 05, 2002 at 09:30:45PM +0100, Gabriel Dos Reis wrote:
| >        const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));
| 
| Err, unsigned int, not unsigned long?

You're absolutely right.

-- Gaby

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Tue, Mar 05, 2002 at 01:11:13PM -0800, Benjamin Kosnik wrote:
| > It's annoying to me to see, for every header with
| > 
| > const int l = 5;
| > 
| > in it, this in every object file
| > 
| > 00000000 r l
| 
| I thought C++ allowed us to never emit these unless their 
| address is taken?  

Yes, that is the case.

| If that's the case, I'd consider this
| a (qoi) bug.

I recall the issue popped up in the past but no action was taken.

-- Gaby

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Tue, Mar 05, 2002 at 01:11:13PM -0800, Benjamin Kosnik wrote:
| > It's annoying to me to see, for every header with
| > 
| > const int l = 5;
| > 
| > in it, this in every object file
| > 
| > 00000000 r l
| 
| I thought C++ allowed us to never emit these unless their 
| address is taken?  If that's the case, I'd consider this
| a (qoi) bug.

Incidently, I think there is a real bug in the compiler.  Here is what
happens:

    // x.H
     exten const int l;

    // x.C
    #include "x.H"
    const int l = 9;	// at this point 'l' should emitted global.

   // y.C
   #include "x.H"

     // y.C references l.

y.o should be successfully linked against x.o.

-- Gaby

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Richard Henderson]

On Wed, Mar 06, 2002 at 08:00:15AM +0100, Gabriel Dos Reis wrote:
> | I thought C++ allowed us to never emit these unless their 
> | address is taken?  
> 
> Yes, that is the case.

Hmm.  A simple test case shows this to be working.

	const int xyzzy = 1;
	int foo() { return xyzzy; }

./cc1plus -O z.c
_Z3foov:
        lda $0,1($31)
        ret $31,($26),1

and xyzzy does not appear in the .s file.


r~

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Richard Henderson]

On Wed, Mar 06, 2002 at 10:21:01AM +0100, Gabriel Dos Reis wrote:
>     // x.H
>      exten const int l;
> 
>     // x.C
>     #include "x.H"
>     const int l = 9;	// at this point 'l' should emitted global.

Ignoring the separate header file for a moment,

	extern const int xyzzy;
	const int xyzzy = 1;

does in fact emit xyzzy to the .s file, and

	extern const int xyzzy;
	int foo() { return xyzzy; }

does in fact reference xyzzy as a symbol.

So if these symbols aren't being referenced properly in some other
situation, someone should come up with a better example.


r~

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Peter Schmid]

Results for g++ 3.1 application testing on i686-pc-linux-gnu (symvers)

Following Benjamins request I upgraded binutils and rerun the test
with symbol versioning enabled. Surprisingly, this time
22_locale/collate_byname.cc from the libstdc++ testsuite fails which
passed on the last run when gcc 20020302 was employed. Could you
please take a look at 22_locale/collate_members_char.cc, which does
not pass either.

Here are the results:

current boost cvs:
All tests pass. There are seven "failures" for empty_* types in
object_type_traits_test.cpp. I do not know why.|

blitz-20001213:
Compiling wei-ku-1.cpp crashes the compiler when
optimization is on. Cf. PR c++/5504 (gcc 3.0 regression).

root_v3.02.07:
Everything works, except for test/bench.cxx, as for gcc 3.0. |

pooma-gcc:
No problems detected. All tests pass. |

Code from Josuttis' Book "The C++ Standard Library": |

Everything works fine, except for the unresolved state of PR libstc++/5133.

stepanov_v1p2.C:

-O
Abstraction Penalty: 1.13
-O2
Abstraction Penalty: 1.32
-O3
Abstraction Penalty: 1.30
-O2  -finline-limit=10000
Abstraction Penalty: 1.27
-O2  -finline-limit=100000
Abstraction Penalty: 1.29

mtl-2.1.2-20:
No problems detected, after applying patches for missing typename
warnings. |

STLport-4.5.3
No problems detected. All tests pass. |

System setup:
SuSE 7.3
Glibc 2.2.4 + patches
Linux 2.4.17
binutils version 020305 20020305
g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.1 20020306 (prerelease)

Hope this helps,

Peter Schmid

Re: Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Benjamin Kosnik]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1397 bytes --]


> Following Benjamins request I upgraded binutils and rerun the test
> with symbol versioning enabled. Surprisingly, this time
> 22_locale/collate_byname.cc from the libstdc++ testsuite fails which
> passed on the last run when gcc 20020302 was employed. Could you
> please take a look at 22_locale/collate_members_char.cc, which does
> not pass either.

These work for the generic code. For the linux codepath, it looks like 
there are some problems with glibc2.2.x and the following:

#define _GNU_SOURCE 1


#include <locale.h>
#include <string.h>
#include <stddef.h>

#define __c_locale __locale_t		

int 
_M_transform_helper(char* __o, const char* __t, size_t __n, __c_locale __loc)
{ return __strxfrm_l(__o, __t, __n, __loc); }

int main()
{
  __c_locale	loc;
  __c_locale	loc_dup;

  const char* 	__s = "de_DE";
  const char* __one = "Äuglein Augmen";
  const char* __two = "Äuglein";
  int i;
  int j;
  size_t __n1;
  size_t __n2;
  char* __c1;
  char* __c2;

  loc = __newlocale(1 << LC_ALL, __s, 0);
  loc_dup = __duplocale(loc);

  __n1 = strlen(__one);
  __n2 = strlen(__two);
  __c1 = __builtin_alloca(__n1);
  __c2 = __builtin_alloca(__n2);
  i = _M_transform_helper(__c1, __one, __n1, loc);
  j = _M_transform_helper(__c2, __two, __n2, loc_dup);

  return 0;
}


At some point (2.2.6?) this will be fixed.

best,
-benjamin

Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Peter Schmid]

I have mixed feelings with the present state of the gcc 3.1 release
candidate. Although there are no regressions with respect to previous
g++ releases concerning conformance to the c++ standard, there are
still, imho severe, regressions with respect to code quality and
the optimizer. Higher optimization levels lead to a pessimization with
respect to -O in some cases, confer the results for the Stepanov and
the oopack tests. This is a regression with respect to gcc 2.95.

Running the test script, tester.pl, from pooma-gcc takes 594.4
seconds user time for gcc 3.0 in contrast to 797.3 seconds for gcc
3.1. In my opinion these compile and code quality regressions should
be resolved before gcc 3.1 is released.

Additionally, I got no feedback on PR fortran/5900, concerning LAPACK
which could be a severe regression.

Here are the results in detail:

stepanov_v1p2.C:

-O0
Abstraction Penalty: 8.45
-O
Abstraction Penalty: 1.06
-O2
Abstraction Penalty: 1.27
-O3
Abstraction Penalty: 1.24
-O2  -finline-limit=10000
Abstraction Penalty: 1.24
-O2  -finline-limit=100000
Abstraction Penalty: 1.27

OOPACK Version 1.7:
Max=100000 Matrix=1000 Complex=100000 Iterator=100000

-O
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Max            100000    1.7   2.1   59.9  48.3    1.2
Matrix           1000    3.5   3.9   70.6  63.6    1.1
Complex        100000    9.4  17.9   84.7  44.7    1.9
Iterator       100000    1.1   2.0  190.5 100.0    1.9

-O2
                         Seconds       Mflops
----       ----------  -----------  -----------  -----
Max            100000    2.0   2.0   50.8  50.8    1.0
Matrix           1000    2.0   2.1  125.0 119.6    1.0
Complex        100000    9.4  26.2   85.1  30.5    2.8
Iterator       100000    1.1   1.3  180.2 157.5    1.1

Max(C) and Complex(OOP) are slower at -O2; Complex is considerably
slower.

current boost cvs:
All tests pass.

blitz-20001213:
All tests pass.

root_v3.03.07:
Everything works, except for test/bench.cxx, as for gcc 3.0.

pooma-gcc:
No problems detected. All tests pass.

Code from Josuttis' Book "The C++ Standard Library":

Everything works fine, except for the unresolved state of PR libstc++/5133.

mtl-2.1.2-20:
No problems detected, after applying patches for missing typename
warnings.

STLport-4.5.3/STLport-5.0-0409
No problems detected. All tests pass.

FTensor--main--1.1--patch-16:
Problems with __restrict__, cf. PR. c++/6392, already fixed on the mainline.
Regression with respect to kcc and icc. Otherwise OK.

ACE 5.2.1:
No problems detected. All tests pass.

System setup:
SuSE 7.3
Glibc 2.2.4 + patches
Linux 2.4.18
GNU ld version 020428 20020428
g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.1 20020505 (prerelease)

Hope this helps,

Peter Schmid

Results for g++ 3.1 application testing on i686-pc-linux-gnu

[Peter Schmid]

There are still problems with the optimizer. Higher optimization
levels lead to a pessimization with respect to -O in some cases,
confer the results for the Stepanov and the oopack tests. This is a
regression with respect to gcc 2.95.

Here are the results:

current boost cvs:
All tests pass.

blitz-20001213:
Compiling wei-ku-1.cpp crashes the compiler when
optimization is on. Cf. PR c++/5504 (gcc 3.0 regression).

root_v3.03.02:
Everything works, except for test/bench.cxx, as for gcc 3.0.

pooma-gcc:
No problems detected. All tests pass.

Code from Josuttis' Book "The C++ Standard Library":

Everything works fine, except for the unresolved state of PR libstc++/5133.

stepanov_v1p2.C:

-O0
Abstraction Penalty: 8.54
-O
Abstraction Penalty: 1.03
-O2
Abstraction Penalty: 1.27
-O3
Abstraction Penalty: 1.26
-O2  -finline-limit=10000
Abstraction Penalty: 1.26
-O2  -finline-limit=100000
Abstraction Penalty: 1.27

OOPACK Version 1.7:
Max=100000 Matrix=1000 Complex=100000 Iterator=100000

-O
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Max            100000    1.6   2.0   61.3  48.8    1.3
Matrix           1000    3.5   4.0   71.0  63.3    1.1
Complex        100000    9.4  17.8   84.7  44.9    1.9
Iterator       100000    1.0   2.0  192.3 100.5    1.9

-O2
                         Seconds       Mflops
Test       Iterations     C    OOP     C    OOP  Ratio
----       ----------  -----------  -----------  -----
Max            100000    1.9   2.0   51.3  51.0    1.0
Matrix           1000    2.0   2.1  125.6 120.8    1.0
Complex        100000    9.4  25.8   85.1  31.0    2.7
Iterator       100000    1.1   1.3  181.8 158.7    1.1

mtl-2.1.2-20:
No problems detected, after applying patches for missing typename
warnings.

STLport-4.5.3/STLport-5.0-0409
No problems detected. All tests pass.

FTensor--main--1.1--patch-16:
No problems detected. All tests pass. Works for the first time.
Compiling some files from the conformance/T4ddg directory takes longer
than half an hour, though (test_T4ddg.C, test_T4ddgV.C). Compiling a
source file from the other directories takes less than a minute.

ACE 5.2.1:
No problems detected. All tests pass.

System setup:
SuSE 7.3
Glibc 2.2.4 + patches
Linux 2.4.18
GNU ld version 020414 20020414
g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.1 20020418 (prerelease)

Hope this helps,

Peter Schmid