Re: GCC 3.2

Re: GCC 3.2

[Benjamin Kosnik]

I've noticed alignment-related bugs in GNATS as well. See libstdc++/6732.

-benjamin

Re: GCC 3.2

[Jakub Jelinek]

On Sat, Jul 27, 2002 at 02:56:14PM -0700, Benjamin Kosnik wrote:
> 
> I've noticed alignment-related bugs in GNATS as well. See libstdc++/6732.

Is that really a bug? __attribute__((aligned(16))) is not part
of C++ standard, and malloc is not guaranteed to return that
much aligned chunks (at least not on all architectures).
E.g. glibc malloc by default only guarantees 2*sizeof(size_t) alignment.

	Jakub

gcc 3.2

[Udo Tremel]

Hi,

I am using the gcc 3.2 C++ compiler and get warnings like

 warning: `typename UTMeshNamespace::MyClass::intT' is implicitly a
typename.

How can I switch only this warning off without deactivating all the
other warnings by the use of -w?

Thanks in advance,

Udo Tremel


--
______________________________________________________________________________

   Udo Tremel

   EADS Military Aircraft
   Flight Physics / Numerical Simulation - MT632
   D-81663 Munich
   Germany

   Phone:  (+49) 89 607-32870
   Fax:    (+49) 89 607-29755
   E-mail: udo.tremel@m.eads.net
______________________________________________________________________________

Re: gcc 3.2

[Mike Stump]

On Wednesday, October 16, 2002, at 03:07 AM, Udo Tremel wrote:
> I am using the gcc 3.2 C++ compiler and get warnings like
>
>  warning: `typename UTMeshNamespace::MyClass::intT' is implicitly a
> typename.
>
> How can I switch only this warning off without deactivating all the
> other warnings by the use of -w?

I suspect your code isn't C++.  I suspect it is close.  I anticipate 
you need an extra typename someplace.  If you showed us a cut down 
testcase that goes through the compiler, I suspect we could say where.

You want to fix your code, not turn off the warning.

Re: GCC 3.2

[Benjamin Kosnik]

> You could certainly do this too.  The idea behind having it done in
> libstdc++ is that we can verify that sizes/layouts of any externally
> visible classes and structures don't change from one rev of libstdc++ to
> another.  That in conjunction with testing the signatures of every
> externally visible function gives us a much better chance of keeping
> libstdc++ compatible from one rev to the next.

Right. I think this is the preferred way to go, it just requires much
(much much much) more work than simply swapping libstdc++.so's.

It looks like LSB is also interested in some kind of solution like this,
so perhaps there is some synergy there.

-benjamin

Re: GCC 3.2

[Gerald Pfeifer]

On Sun, 4 Aug 2002, Joseph S. Myers wrote:
> (Note 1: Java and Fortran maintainers may want to change their manuals to
> use the common version number in gcc-common.texi, for mainline and 3.2.1,
> with the consequent change for branching.html.)

This sounds like an excellent idea.  Toon resp. "Java developers", if
you agree, would you mind making this change?

Gerald

GCC 3.2

[Mark Mitchell]

I have created the GCC 3.2 branch.

Once Jakub indicates that the ABI patchset has been checked in, I will
start rolling the 3.2 prerelease.

Gerald, would you create the GCC 3.2 pages on the web site, if they are
not already there?

The 3.1 branch is now dead; it should no longer be used.  The 3.2
branch (gcc-3_2-branch) is open *only* for C++ ABI fixes.  Once the
GCC 3.2 release is out, it will then become open for regression fixes
again.

We will start stage 3 for the GCC 3.3 release once GCC 3.2 has been
released.

Wow, we are in a maze of twisty little branches...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.2

[Joe Buck]

Mark writes:
> I have created the GCC 3.2 branch.

Cool, and congrats on doing a great job (as usual) with 3.1.1.

> ...
> The 3.1 branch is now dead; it should no longer be used.  The 3.2
> branch (gcc-3_2-branch) is open *only* for C++ ABI fixes.  Once the
> GCC 3.2 release is out, it will then become open for regression fixes
> again.

The http://gcc.gnu.org/gcc-3.1/changes.html page says that we will remove
-traditional in 3.2; clearly this deprecation has moved to 3.3, right?  (I
don't see any reason for making the quick release of 3.2 more
complicated).

Should the web page be updated?  (I haven't spotted any other 3.2 mentions
that need fixing, but that doesn't mean there aren't any).

Re: GCC 3.2

[Mark Mitchell]

--On Friday, July 26, 2002 04:09:35 PM -0700 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

> Mark writes:
>> I have created the GCC 3.2 branch.
>
> Cool, and congrats on doing a great job (as usual) with 3.1.1.
>

Thanks -- and thanks again for your help with the release notes.

> The http://gcc.gnu.org/gcc-3.1/changes.html page says that we will remove
> -traditional in 3.2; clearly this deprecation has moved to 3.3, right?  (I
> don't see any reason for making the quick release of 3.2 more
> complicated).

Yes.

> Should the web page be updated?  (I haven't spotted any other 3.2 mentions
> that need fixing, but that doesn't mean there aren't any).

Yes.  I fixed that.  If there are others, they should be fixed too;
3.2 is just 3.1.1 + ABI patches, and 3.2.1 is just what would have
been 3.1.2 + ABI patches.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.2

[Zack Weinberg]

On Fri, Jul 26, 2002 at 03:50:11PM -0700, Mark Mitchell wrote:
> 
> We will start stage 3 for the GCC 3.3 release once GCC 3.2 has been
> released.

I thought stage 3 did not begin until August 15 in any case.

zw

Re: GCC 3.2

[Mark Mitchell]

--On Friday, July 26, 2002 05:46:09 PM -0700 Zack Weinberg 
<zack@codesourcery.com> wrote:

> On Fri, Jul 26, 2002 at 03:50:11PM -0700, Mark Mitchell wrote:
>>
>> We will start stage 3 for the GCC 3.3 release once GCC 3.2 has been
>> released.
>
> I thought stage 3 did not begin until August 15 in any case.

Ah, good point.  I need to make myself one of those giant horizontal
wall calendars with stripes of different colors on it...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.2

[Toon Moene]

Mark Mitchell wrote:

> --On Friday, July 26, 2002 05:46:09 PM -0700 Zack Weinberg

> > I thought stage 3 did not begin until August 15 in any case.
> 
> Ah, good point.  I need to make myself one of those giant horizontal
> wall calendars with stripes of different colors on it...

Real Programmers have a Snoopy Calendar of '69 hanging on their wall.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.2

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]

On Samstag, 27. Juli 2002 00:50, Mark Mitchell wrote:
> I have created the GCC 3.2 branch.
>
> Once Jakub indicates that the ABI patchset has been checked in, I will
> start rolling the 3.2 prerelease.

Nice :-).

On the ABI patches, shouldn't __GXX_ABI_VERSION be bumped now? I would also 
request this macro to become a generic one, so you can use it while 
preprocessing C and assembly, often used for bridging code like eg. in 
mozilla.

Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a 
short test program with all the alignment stuff the OO people had to change 
between 2.9x and 3.x. Would some of the C++ people take a close look at this 
code? Note that the current ABI patches fixed already 2 problems the OO 
people had to workaround with gcc-3.1, so maybe the others are ABI bugs as 
well?

For example on powerpc-linux-gnu, with gcc-3.1.1:

[fsirl@entropy:~]$ g++ -O2 datatest.cxx -o datatest_nofix
[fsirl@entropy:~]$ ./datatest_nofix
> sizeof(AlignSize_Impl) = 16; __alignof__ (AlignSize_Impl) = 8
> sizeof(M) = 8; __alignof__ (M) = 4
> sizeof(N) = 8; __alignof__ (N) = 4
### sizeof(N) = 8 instead of expected 12!!!
### OFFSET_OF(N, p) = 6 instead of expected 8!!!
> sizeof(N2) = 12; __alignof__ (N2) = 4
> sizeof(O) = 16; __alignof__ (O) = 8
> sizeof(D) = 8; __alignof__ (D) = 4
> sizeof(C1) = 2; __alignof__ (C1) = 2
> sizeof(C2) = 8; __alignof__ (C2) = 4
> sizeof(C3) = 24; __alignof__ (C3) = 8
> sizeof(C4) = 32; __alignof__ (C4) = 8
### sizeof(C4) = 32 instead of expected 40!!!
### OFFSET_OF(C4, n4) = 20 instead of expected 24!!!
### OFFSET_OF(C4, d4) = 24 instead of expected 32!!!
> sizeof(C5) = 48; __alignof__ (C5) = 8
### sizeof(C5) = 48 instead of expected 56!!!
### OFFSET_OF(C5, n5) = 32 instead of expected 40!!!
### OFFSET_OF(C5, b5) = 40 instead of expected 48!!!
> sizeof(C6) = 64; __alignof__ (C6) = 8
### sizeof(C6) = 64 instead of expected 72!!!
### OFFSET_OF(C6, b6) = 56 instead of expected 64!!!
> sizeof(O2) = 24; __alignof__ (O2) = 8
> sizeof(Char3) = 3; __alignof__ (Char3) = 1
> sizeof(P) = 16; __alignof__ (P) = 8
### sizeof(P) = 16 instead of expected 24!!!
> sizeof(second) = 4; __alignof__ (second) = 4

And now with gcc-3.2:

[fsirl@entropy:~]$ ~/obj/gcc32/gcc/xgcc -B ~/obj/gcc32/gcc/ -O2 datatest.cxx 
-o datatest_nofix
[fsirl@entropy:~]$ ./datatest_nofix
> sizeof(AlignSize_Impl) = 16; __alignof__ (AlignSize_Impl) = 8
> sizeof(M) = 8; __alignof__ (M) = 4
> sizeof(N) = 12; __alignof__ (N) = 4
> sizeof(N2) = 12; __alignof__ (N2) = 4
> sizeof(O) = 16; __alignof__ (O) = 8
> sizeof(D) = 8; __alignof__ (D) = 4
> sizeof(C1) = 2; __alignof__ (C1) = 2
> sizeof(C2) = 8; __alignof__ (C2) = 4
> sizeof(C3) = 24; __alignof__ (C3) = 8
> sizeof(C4) = 32; __alignof__ (C4) = 8
### sizeof(C4) = 32 instead of expected 40!!!
### OFFSET_OF(C4, n4) = 20 instead of expected 24!!!
### OFFSET_OF(C4, d4) = 24 instead of expected 32!!!
> sizeof(C5) = 48; __alignof__ (C5) = 8
### sizeof(C5) = 48 instead of expected 56!!!
### OFFSET_OF(C5, n5) = 32 instead of expected 40!!!
### OFFSET_OF(C5, b5) = 40 instead of expected 48!!!
> sizeof(C6) = 64; __alignof__ (C6) = 8
### sizeof(C6) = 64 instead of expected 72!!!
### OFFSET_OF(C6, b6) = 56 instead of expected 64!!!
> sizeof(O2) = 24; __alignof__ (O2) = 8
> sizeof(Char3) = 3; __alignof__ (Char3) = 1
> sizeof(P) = 24; __alignof__ (P) = 8
> sizeof(second) = 4; __alignof__ (second) = 4

If you add -DADJUST_ALIGN to the compile flags, the OO workarounds are turned 
on the the testcase passes with gcc-3.1.1 and gcc-3.2.

Franz.


[-- Attachment #2: datatest.cxx --]
[-- Type: text/plain, Size: 5432 bytes --]

#include <stdlib.h>
#include <stdio.h>


typedef struct _Any
{
        void * pType;
        void * pData;
        void * pReserved;
} uno_Any;

typedef _Any Any;


// Patching the gcc 3 incompatible alignment change for linux
// This pragma macro is appended to every first member of a struct, 
// iff the struct inherits from a base struct and the first member
// of this structure  is not a double or [unsigned] long long.

#ifdef ADJUST_ALIGN

#define CPPU_GCC3_ALIGN( base_struct ) __attribute__ ((aligned (__alignof__ (base_struct))))

#else

#define CPPU_GCC3_ALIGN( base_struct )

#endif


typedef enum {
        My_BYTE,
        MY_CHAR,
        MY_INT,
        MY_LONG,
        MY_LONGLONG,
        MY_FLOAT,
        MY_DOUBLE
} TypeClass;



#if defined(__GNUC__) && defined(__linux__) && defined(__intel__)
#define MAX_ALIGNMENT_4
#endif

#define OFFSET_OF( s, m ) ((size_t)((char *)&((s *)16)->m -16))

#define BINTEST_VERIFY( c ) \
    if (! (c)) { fprintf( stderr, "### binary compatibility test failed: " #c " [line %d]!!!\n", __LINE__ );  }

#define BINTEST_VERIFYOFFSET( s, m, n ) \
    if (OFFSET_OF(s, m) != n) { fprintf( stderr, "### OFFSET_OF(" #s ", "  #m ") = %d instead of expected %d!!!\n", OFFSET_OF(s, m), n );  }

#define BINTEST_VERIFYSIZE( s, n ) \
    fprintf( stderr, "> sizeof(" #s ") = %d; __alignof__ (" #s ") = %d\n", sizeof(s), __alignof__ (s) ); \
    if (sizeof(s) != n) { fprintf( stderr, "### sizeof(" #s ") = %d instead of expected %d!!!\n", sizeof(s), n );  }


struct C1
{
    signed short n1;
};
struct C2 : public C1
{
    signed long n2 CPPU_GCC3_ALIGN( C1 );
};
struct C3 : public C2
{
    double d3;
    signed long n3;
};
struct C4 : public C3
{
    signed long n4 CPPU_GCC3_ALIGN( C3 );
    double d4;
};
struct C5 : public C4
{
    signed long long n5;
    unsigned char b5;
};
struct C6 : public C1
{
    C5 c6 CPPU_GCC3_ALIGN( C1 );
    unsigned char b6;
};

struct D
{
    signed short d;
    signed long e;
};
struct E
{
    unsigned char a;
    unsigned char b;
    unsigned char c;
    signed short d;
    signed long e;
};

struct M
{ 
	signed long	n;
	signed short	o;
};

struct N : public M
{ 
	signed short	p CPPU_GCC3_ALIGN( M );
};
struct N2
{
    M m;
	signed short	p;
};

struct O : public M
{ 
	double	p;
};
struct O2 : public O
{ 
	double	p2;
};

struct P : public N
{ 
	double	p2;
};

struct empty
{
};

struct second : public empty
{
	int a;
};

struct AlignSize_Impl
{
	signed short	nInt16;
	double		dDouble;
};

struct Char1
{
    char c1;
};
struct Char2 : public Char1
{
    char c2 CPPU_GCC3_ALIGN( Char1 );
};
struct Char3 : public Char2
{
    char c3 CPPU_GCC3_ALIGN( Char2 );
};
struct Char4
{
    Char3 chars;
    char c;
};

class BinaryCompatible_Impl
{
public:
	BinaryCompatible_Impl();
};

BinaryCompatible_Impl::BinaryCompatible_Impl()
{
#ifdef MAX_ALIGNMENT_4
    // max alignment is 4
    BINTEST_VERIFYOFFSET( AlignSize_Impl, dDouble, 4 );
    BINTEST_VERIFYSIZE( AlignSize_Impl, 12 );
#else
    // max alignment is 8
    BINTEST_VERIFYOFFSET( AlignSize_Impl, dDouble, 8 );
    BINTEST_VERIFYSIZE( AlignSize_Impl, 16 );
#endif
    
    // enum
    BINTEST_VERIFY( sizeof( TypeClass ) == sizeof( signed long ) );

    // any
    BINTEST_VERIFY( sizeof(void *) >= sizeof(signed long) );
    BINTEST_VERIFY( sizeof( Any ) == sizeof( _Any ) );
    BINTEST_VERIFY( sizeof( Any ) == sizeof( void * ) * 3 );
    BINTEST_VERIFYOFFSET( Any, pType, 0 );
    BINTEST_VERIFYOFFSET( Any, pData, 4 );
    BINTEST_VERIFYOFFSET( Any, pReserved, 8 );

    // struct
    BINTEST_VERIFYSIZE( M, 8 );
    BINTEST_VERIFYOFFSET( M, o, 4 );
    BINTEST_VERIFYSIZE( N, 12 );
    BINTEST_VERIFYOFFSET( N, p, 8 );
    BINTEST_VERIFYSIZE( N2, 12 );
    BINTEST_VERIFYOFFSET( N2, p, 8 );
    BINTEST_VERIFYSIZE( O, 16 );
    BINTEST_VERIFYSIZE( D, 8 );
    BINTEST_VERIFYOFFSET( D, e, 4 );
    BINTEST_VERIFYOFFSET( E, d, 4 );
    BINTEST_VERIFYOFFSET( E, e, 8 );

    BINTEST_VERIFYSIZE( C1, 2 );
    BINTEST_VERIFYSIZE( C2, 8 );
    BINTEST_VERIFYOFFSET( C2, n2, 4 );

#ifdef MAX_ALIGNMENT_4
    BINTEST_VERIFYSIZE( C3, 20 );
    BINTEST_VERIFYOFFSET( C3, d3, 8 );
    BINTEST_VERIFYOFFSET( C3, n3, 16 );
    BINTEST_VERIFYSIZE( C4, 32 );
    BINTEST_VERIFYOFFSET( C4, n4, 20 );
    BINTEST_VERIFYOFFSET( C4, d4, 24 );
    BINTEST_VERIFYSIZE( C5, 44 );
    BINTEST_VERIFYOFFSET( C5, n5, 32 );
    BINTEST_VERIFYOFFSET( C5, b5, 40 );
    BINTEST_VERIFYSIZE( C6, 52 );
    BINTEST_VERIFYOFFSET( C6, c6, 4 );
    BINTEST_VERIFYOFFSET( C6, b6, 48 );
#else
    BINTEST_VERIFYSIZE( C3, 24 );
    BINTEST_VERIFYOFFSET( C3, d3, 8 );
    BINTEST_VERIFYOFFSET( C3, n3, 16 );
    BINTEST_VERIFYSIZE( C4, 40 );
    BINTEST_VERIFYOFFSET( C4, n4, 24 );
    BINTEST_VERIFYOFFSET( C4, d4, 32 );
    BINTEST_VERIFYSIZE( C5, 56 );
    BINTEST_VERIFYOFFSET( C5, n5, 40 );
    BINTEST_VERIFYOFFSET( C5, b5, 48 );
    BINTEST_VERIFYSIZE( C6, 72 );
    BINTEST_VERIFYOFFSET( C6, c6, 8 );
    BINTEST_VERIFYOFFSET( C6, b6, 64 );
#endif

    BINTEST_VERIFYSIZE( O2, 24 );    
    BINTEST_VERIFYOFFSET( O2, p2, 16 );
    
    BINTEST_VERIFYSIZE( Char3, 3 );
    BINTEST_VERIFYOFFSET( Char4, c, 3 );
    
#ifdef MAX_ALIGNMENT_4
    // max alignment is 4
    BINTEST_VERIFYSIZE( P, 20 );
#else
    // alignment of P is 8, because of P[] ...
    BINTEST_VERIFYSIZE( P, 24 );
    BINTEST_VERIFYSIZE( second, sizeof( int ) );
#endif
}

static BinaryCompatible_Impl aTest;

int main ()
{
  exit(0);
}

Re: GCC 3.2

[Jakub Jelinek]

On Sat, Jul 27, 2002 at 04:35:12PM +0200, Franz Sirl wrote:
> On Samstag, 27. Juli 2002 00:50, Mark Mitchell wrote:
> > I have created the GCC 3.2 branch.
> >
> > Once Jakub indicates that the ABI patchset has been checked in, I will
> > start rolling the 3.2 prerelease.
> 
> Nice :-).
> 
> On the ABI patches, shouldn't __GXX_ABI_VERSION be bumped now? I would also 
> request this macro to become a generic one, so you can use it while 
> preprocessing C and assembly, often used for bridging code like eg. in 
> mozilla.
> 
> Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a 
> short test program with all the alignment stuff the OO people had to change 
> between 2.9x and 3.x. Would some of the C++ people take a close look at this 
> code? Note that the current ABI patches fixed already 2 problems the OO 
> people had to workaround with gcc-3.1, so maybe the others are ABI bugs as 
> well?

I have tried it on ia32, with gcc 2.95.x, 2.96-RH, 3.1.1 and 3.2 CVS.
The first 2 were identical, but showed several for the testcase unexpected
results, 3.1.1 was worse and 3.2 is actually better than 2.9* according to
the testcase expectations (with 2.9*
> sizeof(second) = 8; __alignof__ (second) = 4
### sizeof(second) = 8 instead of expected 4!!!
while with 3.2 CVS
> sizeof(second) = 4; __alignof__ (second) = 4
where second is:
struct empty { };
struct second : public empty { int a; };

But I agree we should look at all the classes in the
testcase and check the ABI what values should it really give (then adapt
into a testcase and commit).

	Jakub

Re: GCC 3.2

[Jason Merrill]

On Sat, 27 Jul 2002 16:35:12 +0200, Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote:

> Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a 
> short test program with all the alignment stuff the OO people had to change 
> between 2.9x and 3.x. Would some of the C++ people take a close look at this 
> code? Note that the current ABI patches fixed already 2 problems the OO 
> people had to workaround with gcc-3.1, so maybe the others are ABI bugs as 
> well?
>
> And now with gcc-3.2:
>
> ### sizeof(C4) = 32 instead of expected 40!!!
> ### OFFSET_OF(C4, n4) = 20 instead of expected 24!!!
> ### OFFSET_OF(C4, d4) = 24 instead of expected 32!!!

This is not a bug.  What's happening is that when we lay out C4, we
allocate n4 into the tail padding of C3.  We can do this because C3 is not
a POD type; we just need to be careful not to copy the tail padding when we
assign to a C3.  The ABI bug I fixed was that we were doing this with POD
bases as well, which is broken because POD classes must be compatible with
C code.

It's possible that we are copying the tail padding when assigning a C3; I'm
not seeing that, but am continuing to investigate.  If so, that's a serious
bug, but fixing it will not impact the ABI.  In other words, it can wait
for 3.2.1.

Jason

Re: GCC 3.2

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

On Tue, 30 Jul 2002 00:32:14 +0100, Jason Merrill <jason@redhat.com> wrote:

> It's possible that we are copying the tail padding when assigning a C3; I'm
> not seeing that, but am continuing to investigate.

Indeed we are; I needed to specify -malign-double so there would be tail
padding on the x86 for us to handle wrong.  :)

> If so, that's a serious bug, but fixing it will not impact the ABI.  In
> other words, it can wait for 3.2.1.

This is still true, but I have a preliminary patch for which testing is not
yet complete, which adds a langhook to expr_size.  I believe that returning
the unpadded size from expr_size is correct, as expr_size is interested in
the value, not the allocated space.  Comments welcome.  The other option
was to add another size field to types; a langhook seemed more
space-efficient.

With this patch, the empty class passing hackery can go away, hurrah.

BTW, why do we use stubs for langhook defaults?  I would think leaving the
hook entry NULL would be more efficient for languages that are happy with
the default, as a comparison to zero is much cheaper than an indirect
jump...

2002-07-31  Jason Merrill  <jason@redhat.com>

	* langhooks-def.h (LANG_HOOKS_EXPR_SIZE): New macro.
	* langhooks.c (lhd_expr_size): Define default.
	* langhooks.h (struct lang_hooks): Add expr_size.
	* explow.c (expr_size): Call it.

2002-07-31  Jason Merrill  <jason@redhat.com>

	* class.c (cp_expr_size): New fn.
	* cp-tree.h: Declare it.
	* cp-lang.c (LANG_HOOKS_EXPR_SIZE): Define.
	* call.c (build_over_call): Lose empty class hackery.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 7470 bytes --]

*** ./cp/class.c.~1~	Tue Jul 30 00:43:54 2002
--- ./cp/class.c	Tue Jul 30 17:49:25 2002
*************** build_vtable_entry (delta, vcall_index, 
*** 8048,8050 ****
--- 8048,8065 ----
  #endif
    return entry;
  }
+ 
+ /* Langhook for expr_size: Tell the backend that the value of an expression
+    of non-POD class type does not include any tail padding; a derived class
+    might have allocated something there.  */
+ 
+ tree
+ cp_expr_size (exp)
+      tree exp;
+ {
+   if (CLASS_TYPE_P (TREE_TYPE (exp)))
+     return CLASSTYPE_SIZE_UNIT (TREE_TYPE (exp));
+   else
+     /* Use the default code.  */
+     return NULL_TREE;
+ }
*** ./cp/cp-lang.c.~1~	Sun May 26 17:23:43 2002
--- ./cp/cp-lang.c	Tue Jul 30 15:41:20 2002
*************** static HOST_WIDE_INT cxx_get_alias_set P
*** 91,96 ****
--- 91,98 ----
  #define LANG_HOOKS_TREE_DUMP_DUMP_TREE_FN cp_dump_tree
  #undef LANG_HOOKS_TREE_DUMP_TYPE_QUALS_FN
  #define LANG_HOOKS_TREE_DUMP_TYPE_QUALS_FN cp_type_quals
+ #undef LANG_HOOKS_EXPR_SIZE
+ #define LANG_HOOKS_EXPR_SIZE cp_expr_size
  
  /* Each front end provides its own hooks, for toplev.c.  */
  const struct lang_hooks lang_hooks = LANG_HOOKS_INITIALIZER;
*** ./cp/cp-tree.h.~1~	Tue Jul 30 00:43:55 2002
--- ./cp/cp-tree.h	Tue Jul 30 15:52:07 2002
*************** extern tree get_vtbl_decl_for_binfo     
*** 3628,3633 ****
--- 3628,3634 ----
  extern tree in_charge_arg_for_name              PARAMS ((tree));
  extern tree get_vtt_name                        PARAMS ((tree));
  extern tree get_primary_binfo                   PARAMS ((tree));
+ extern tree cp_expr_size			PARAMS ((tree));
  
  /* in cvt.c */
  extern tree convert_to_reference		PARAMS ((tree, tree, int, int, tree));
*** ./cp/call.c.~1~	Thu May  9 16:55:25 2002
--- ./cp/call.c	Tue Jul 30 17:42:58 2002
*************** build_over_call (cand, args, flags)
*** 4298,4312 ****
  	  else if (TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn)))
  	    return build_target_expr_with_type (arg, DECL_CONTEXT (fn));
  	}
!       else if ((!real_lvalue_p (arg)
! 		|| TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn)))
! 	       /* Empty classes have padding which can be hidden
! 	          inside an (empty) base of the class. This must not
! 	          be touched as it might overlay things. When the
! 	          gcc core learns about empty classes, we can treat it
! 	          like other classes. */
! 	       && !(is_empty_class (DECL_CONTEXT (fn))
! 		    && TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn))))
  	{
  	  tree address;
  	  tree to = stabilize_reference
--- 4298,4305 ----
  	  else if (TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn)))
  	    return build_target_expr_with_type (arg, DECL_CONTEXT (fn));
  	}
!       else if (!real_lvalue_p (arg)
! 	       || TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn)))
  	{
  	  tree address;
  	  tree to = stabilize_reference
*************** build_over_call (cand, args, flags)
*** 4328,4351 ****
  	(build_indirect_ref (TREE_VALUE (converted_args), 0));
  
        arg = build_indirect_ref (TREE_VALUE (TREE_CHAIN (converted_args)), 0);
!       if (is_empty_class (TREE_TYPE (to)))
! 	{
! 	  TREE_USED (arg) = 1;
! 
! 	  val = build (COMPOUND_EXPR, DECL_CONTEXT (fn), arg, to);
! 	  /* Even though the assignment may not actually result in any
! 	     code being generated, we do not want to warn about the
! 	     assignment having no effect.  That would be confusing to
! 	     users who may be performing the assignment as part of a
! 	     generic algorithm, for example.
! 	     
! 	     Ideally, the notions of having side-effects and of being
! 	     useless would be orthogonal.  */
! 	  TREE_SIDE_EFFECTS (val) = 1;
! 	  TREE_NO_UNUSED_WARNING (val) = 1;
! 	}
!       else
! 	val = build (MODIFY_EXPR, TREE_TYPE (to), to, arg);
        return val;
      }
  
--- 4321,4327 ----
  	(build_indirect_ref (TREE_VALUE (converted_args), 0));
  
        arg = build_indirect_ref (TREE_VALUE (TREE_CHAIN (converted_args)), 0);
!       val = build (MODIFY_EXPR, TREE_TYPE (to), to, arg);
        return val;
      }
  
*** ./explow.c.~1~	Sun Mar 17 17:48:49 2002
--- ./explow.c	Tue Jul 30 17:36:43 2002
*************** Software Foundation, 59 Temple Place - S
*** 34,39 ****
--- 34,40 ----
  #include "insn-config.h"
  #include "ggc.h"
  #include "recog.h"
+ #include "langhooks.h"
  
  static rtx break_out_memory_refs	PARAMS ((rtx));
  static void emit_stack_probe		PARAMS ((rtx));
*************** rtx
*** 285,294 ****
  expr_size (exp)
       tree exp;
  {
!   tree size;
  
!   if (TREE_CODE_CLASS (TREE_CODE (exp)) == 'd'
!       && DECL_SIZE_UNIT (exp) != 0)
      size = DECL_SIZE_UNIT (exp);
    else
      size = size_in_bytes (TREE_TYPE (exp));
--- 286,297 ----
  expr_size (exp)
       tree exp;
  {
!   tree size = (*lang_hooks.expr_size) (exp);
  
!   if (size)
!     /* The frontend specified a size.  */;
!   else if (TREE_CODE_CLASS (TREE_CODE (exp)) == 'd'
! 	   && DECL_SIZE_UNIT (exp) != 0)
      size = DECL_SIZE_UNIT (exp);
    else
      size = size_in_bytes (TREE_TYPE (exp));
*************** expr_size (exp)
*** 298,304 ****
      size = build (WITH_RECORD_EXPR, sizetype, size, exp);
  
    return expand_expr (size, NULL_RTX, TYPE_MODE (sizetype), 0);
- 
  }
  \f
  /* Return a copy of X in which all memory references
--- 301,306 ----
*** ./langhooks.h.~1~	Sun May 26 17:22:52 2002
--- ./langhooks.h	Tue Jul 30 17:41:11 2002
*************** struct lang_hooks
*** 156,161 ****
--- 156,165 ----
       warning that the front end does not use such a parser.  */
    void (*set_yydebug) PARAMS ((int));
  
+   /* Called from expr_size to calculate the size of the value of an
+      expression in a language-dependent way.  */
+   tree (*expr_size) PARAMS ((tree));
+ 
    struct lang_hooks_for_tree_inlining tree_inlining;
    
    struct lang_hooks_for_tree_dump tree_dump;
*** ./langhooks-def.h.~1~	Sun May 26 17:22:51 2002
--- ./langhooks-def.h	Tue Jul 30 16:02:44 2002
*************** extern int lhd_staticp PARAMS ((tree));
*** 48,53 ****
--- 48,54 ----
  extern void lhd_clear_binding_stack PARAMS ((void));
  extern void lhd_print_tree_nothing PARAMS ((FILE *, tree, int));
  extern void lhd_set_yydebug PARAMS ((int));
+ extern tree lhd_expr_size PARAMS ((tree));
  
  /* Declarations of default tree inlining hooks.  */
  tree lhd_tree_inlining_walk_subtrees		PARAMS ((tree *, int *,
*************** tree lhd_tree_inlining_convert_parm_for_
*** 85,90 ****
--- 86,92 ----
  #define LANG_HOOKS_PRINT_TYPE		lhd_print_tree_nothing
  #define LANG_HOOKS_PRINT_IDENTIFIER	lhd_print_tree_nothing
  #define LANG_HOOKS_SET_YYDEBUG		lhd_set_yydebug
+ #define LANG_HOOKS_EXPR_SIZE		lhd_expr_size
  
  /* Tree inlining hooks.  */
  #define LANG_HOOKS_TREE_INLINING_WALK_SUBTREES lhd_tree_inlining_walk_subtrees
*************** int lhd_tree_dump_type_quals			PARAMS ((
*** 156,161 ****
--- 158,164 ----
    LANG_HOOKS_PRINT_TYPE, \
    LANG_HOOKS_PRINT_IDENTIFIER, \
    LANG_HOOKS_SET_YYDEBUG, \
+   LANG_HOOKS_EXPR_SIZE, \
    LANG_HOOKS_TREE_INLINING_INITIALIZER, \
    LANG_HOOKS_TREE_DUMP_INITIALIZER \
  }
*** ./langhooks.c.~1~	Wed Apr  3 20:59:05 2002
--- ./langhooks.c	Tue Jul 30 17:40:03 2002
*************** lhd_tree_dump_type_quals (t)
*** 303,305 ****
--- 303,314 ----
    return TYPE_QUALS (t);
  }
  
+ /* lang_hooks.expr_size: Determine the size of the value of an expression T
+    in a language-specific way.  */
+ 
+ tree
+ lhd_expr_size (t)
+      tree t ATTRIBUTE_UNUSED;
+ {
+   return NULL_TREE;
+ }

Re: GCC 3.2

[Jason Merrill]

On Wed, 31 Jul 2002 01:49:35 +0100, Jason Merrill <jason@redhat.com> wrote:

> This is still true, but I have a preliminary patch for which testing is not
> yet complete, which adds a langhook to expr_size.  I believe that returning
> the unpadded size from expr_size is correct, as expr_size is interested in
> the value, not the allocated space.  Comments welcome.  The other option
> was to add another size field to types; a langhook seemed more
> space-efficient.
>
> With this patch, the empty class passing hackery can go away, hurrah.

Well, the patch seems to break empty class tests, so more refinement is
needed.  Comments on the strategy still welcome.

Jason

Re: GCC 3.2

[Neil Booth]

Jason Merrill wrote:-

> BTW, why do we use stubs for langhook defaults?  I would think leaving the
> hook entry NULL would be more efficient for languages that are happy with
> the default, as a comparison to zero is much cheaper than an indirect
> jump...

Mark requested it be done like this.  I think he liked the parallel with
virtual functions.

Neil.

Re: GCC 3.2

[Neil Booth]

Jason Merrill wrote:-

> +   /* Called from expr_size to calculate the size of the value of an
> +      expression in a language-dependent way.  */
> +   tree (*expr_size) PARAMS ((tree));

Please also document what the return value means and can be.

Neil.

Re: GCC 3.2

[Joseph S. Myers]

On Wed, 31 Jul 2002, Neil Booth wrote:

> Jason Merrill wrote:-
> 
> > +   /* Called from expr_size to calculate the size of the value of an
> > +      expression in a language-dependent way.  */
> > +   tree (*expr_size) PARAMS ((tree));
> 
> Please also document what the return value means and can be.

It's about time langhooks were actually documented in the internals
manual, rather than just keeping adding them on the basis that someone
will add proper documentation later.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.2

[Mark Mitchell]

> With this patch, the empty class passing hackery can go away, hurrah.

Yay.

> BTW, why do we use stubs for langhook defaults?  I would think leaving the
> hook entry NULL would be more efficient for languages that are happy with
> the default, as a comparison to zero is much cheaper than an indirect
> jump...

Well, what I would do is simply move the current expr_size_unit into the
new hook.  Then, have the C++ hook call the generic hook if it doesn't
want to override it.

+ tree
+ cp_expr_size (exp)
+      tree exp;
+ {
+   if (CLASS_TYPE_P (TREE_TYPE (exp)))
+     return CLASSTYPE_SIZE_UNIT (TREE_TYPE (exp));
+   else
+     /* Use the default code.  */
+     return NULL_TREE;
+ }

Isn't that the size without virtual base classes?  What if the expression
is for a complete object with virtual bases?

A good answer is that in that case the C++ front end will never present
the back end with an expression like that requiring copying.  In that
case, there should be an assert and a comment indicating that in
cp_expr_size so that we can tell if we screw up.

Overall, I think I'd rather we wait for 3.2.1 for this patch -- but then
I think it's a good idea.

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.2

[Jason Merrill]

On Wed, 31 Jul 2002 08:57:17 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

>> With this patch, the empty class passing hackery can go away, hurrah.
>
> Yay.
>
>> BTW, why do we use stubs for langhook defaults?  I would think leaving the
>> hook entry NULL would be more efficient for languages that are happy with
>> the default, as a comparison to zero is much cheaper than an indirect
>> jump...
>
> Well, what I would do is simply move the current expr_size_unit into the
> new hook.  Then, have the C++ hook call the generic hook if it doesn't
> want to override it.

Could do that, I suppose.

> + tree
> + cp_expr_size (exp)
> +      tree exp;
> + {
> +   if (CLASS_TYPE_P (TREE_TYPE (exp)))
> +     return CLASSTYPE_SIZE_UNIT (TREE_TYPE (exp));
> +   else
> +     /* Use the default code.  */
> +     return NULL_TREE;
> + }
>
> Isn't that the size without virtual base classes?  What if the expression
> is for a complete object with virtual bases?
>
> A good answer is that in that case the C++ front end will never present
> the back end with an expression like that requiring copying.  In that
> case, there should be an assert and a comment indicating that in
> cp_expr_size so that we can tell if we screw up.

Good thought.  Indeed, adding such an assert exposes a long-standing bug
with g++.bugs/900331_03.C where a SAVE_EXPR was causing us to bitwise copy
a class for which that is inappropriate.  Will fix.

> Overall, I think I'd rather we wait for 3.2.1 for this patch -- but then
> I think it's a good idea.

That's what I was thinking.  I'm also thinking to reserve the empty class
bits for the trunk, to be safe.

Jason

Re: GCC 3.2

[Jeff Law]

 In message <200207271635.12319@enzo.bigblue.local>, Franz Sirl writes:
 >On Samstag, 27. Juli 2002 00:50, Mark Mitchell wrote:
 >> I have created the GCC 3.2 branch.
 >>
 >> Once Jakub indicates that the ABI patchset has been checked in, I will
 >> start rolling the 3.2 prerelease.
 >
 [ ... ]

 >Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a 
 >short test program with all the alignment stuff the OO people had to change 
 >between 2.9x and 3.x. Would some of the C++ people take a close look at this 
 >code? Note that the current ABI patches fixed already 2 problems the OO 
 >people had to workaround with gcc-3.1, so maybe the others are ABI bugs as 
 >well?
This reminds me of another ABI testing infrastructure we could build out.

Many many years ago Cygnus wrote some patches for a customer which allowed
GCC to dump out various things like size/offset information for structure
members.

It seems to me we could do something similar, but with more coverage and
with the data in a format more suitable for testing (the customer used
that information to build accessor macros for assembly code so that it 
could easily access fields within C structures).

Anyway, given that kind of information it would be fairly straightforward
to run code through two revs of the compiler and compare the dumped 
information.
We could actually make this part of the libstdc++ testsuite by having 
reference data for each target.

jeff

Re: GCC 3.2

[Jakub Jelinek]

On Mon, Aug 12, 2002 at 09:51:21AM -0600, Jeff Law wrote:
>  In message <200207271635.12319@enzo.bigblue.local>, Franz Sirl writes:
>  >On Samstag, 27. Juli 2002 00:50, Mark Mitchell wrote:
>  >> I have created the GCC 3.2 branch.
>  >>
>  >> Once Jakub indicates that the ABI patchset has been checked in, I will
>  >> start rolling the 3.2 prerelease.
>  >
>  [ ... ]
> 
>  >Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a 
>  >short test program with all the alignment stuff the OO people had to change 
>  >between 2.9x and 3.x. Would some of the C++ people take a close look at this 
>  >code? Note that the current ABI patches fixed already 2 problems the OO 
>  >people had to workaround with gcc-3.1, so maybe the others are ABI bugs as 
>  >well?
> This reminds me of another ABI testing infrastructure we could build out.
> 
> Many many years ago Cygnus wrote some patches for a customer which allowed
> GCC to dump out various things like size/offset information for structure
> members.

You mean gcc/testsuite/consistency.vlad stuff?
I've run that on various compilers, the
only thing which was different between 3.3 20020803 and 3.2 20020803 was
__alignof__ of top level objects, but it did not catch e.g. the bitfield
layout problems.

IMHO it would be better to write a layout test generator, using all
combinations for the simpler tests and pick some hundreds tests at random for
more complicated tests.

	Jakub

Re: GCC 3.2

[Vladimir Makarov]

Jakub Jelinek wrote:
> 
> On Mon, Aug 12, 2002 at 09:51:21AM -0600, Jeff Law wrote:
> >  In message <200207271635.12319@enzo.bigblue.local>, Franz Sirl writes:
> >  >On Samstag, 27. Juli 2002 00:50, Mark Mitchell wrote:
> >  >> I have created the GCC 3.2 branch.
> >  >>
> >  >> Once Jakub indicates that the ABI patchset has been checked in, I will
> >  >> start rolling the 3.2 prerelease.
> >  >
> >  [ ... ]
> >
> >  >Another thing, Kevin Hendricks, one of the OpenOffice developers, sent me a
> >  >short test program with all the alignment stuff the OO people had to change
> >  >between 2.9x and 3.x. Would some of the C++ people take a close look at this
> >  >code? Note that the current ABI patches fixed already 2 problems the OO
> >  >people had to workaround with gcc-3.1, so maybe the others are ABI bugs as
> >  >well?
> > This reminds me of another ABI testing infrastructure we could build out.
> >
> > Many many years ago Cygnus wrote some patches for a customer which allowed
> > GCC to dump out various things like size/offset information for structure
> > members.
> 
> You mean gcc/testsuite/consistency.vlad stuff?
> I've run that on various compilers, the
> only thing which was different between 3.3 20020803 and 3.2 20020803 was
> __alignof__ of top level objects, but it did not catch e.g. the bitfield
> layout problems.
> 
> IMHO it would be better to write a layout test generator, using all
> combinations for the simpler tests and pick some hundreds tests at random for
> more complicated tests.

  Actually, the tests were generated and they were generated according
to your proposal.  There are lot of combinations for bitfields,
therefore they were chosen randomly.

  The customer wanted more therefore tests from all customer's system
structures (several millions C++ lines) were generated too.  They can
not be added because it requires proprietary code.  The test generator
was written on compiler-compiler named Gentle 4-4.5 years ago.

  I think the approach could be useful and we could use gcc front-end to
generate tests from big and important programs.

  Another approach could be generation of tests taking all GCC memory
allocation macros into account.  The tests in consistency.vlad were
written according "black box" approach.

  The testsuite can be divided on two parts:
    1. dejagnu code
    2. and the tests themselves.

  The first part is still flexible and could be used without changes for
new tests.

Vlad

Re: GCC 3.2

[Jeff Law]

 In message < 20020812180910.K18963@sunsite.ms.mff.cuni.cz >, Jakub Jelinek 
writes:
 >You mean gcc/testsuite/consistency.vlad stuff?
Nope.  This was something rather different.  We had hooks in the compiler
itself to dump out structure layouts for use by assembly coders.

It didn't even occur to us to use that infrastructure to solve the problem
that Vlad's layout checker solves.  The offset-info stuff would need some
beefing up, but it shouldn't be a terrible task.

 >IMHO it would be better to write a layout test generator, using all
 >combinations for the simpler tests and pick some hundreds tests at random for
 >more complicated tests.
You could certainly do this too.  The idea behind having it done in libstdc++
is that we can verify that sizes/layouts of any externally visible classes
and structures don't change from one rev of libstdc++ to another.  That
in conjunction with testing the signatures of every externally visible
function gives us a much better chance of keeping libstdc++ compatible 
from one rev to the next.

jeff

Re: GCC 3.2

[Jakub Jelinek]

On Mon, Aug 12, 2002 at 02:32:22PM -0600, Jeff Law wrote:
> The idea behind having it done in libstdc++
> is that we can verify that sizes/layouts of any externally visible classes
> and structures don't change from one rev of libstdc++ to another.  That
> in conjunction with testing the signatures of every externally visible
> function gives us a much better chance of keeping libstdc++ compatible 
> from one rev to the next.

Completely agreed.

	Jakub

Re: GCC 3.2

[Janis Johnson]

There are many things that can break compatibility between two releases
of a C++ compiler or between two different compilers that are expected
to be binary compatible.  In a previous position I set up some tests to
help detect such breakage between one release and another.  They
occasionally found things like entry points that were thought to no
longer be needed in runtime support libraries, or conflicts between
symbols in shared objects.  These were tests of compatibility for the
compiler and its run-time support, not for functionality within the
Standard C++ Library.

Existing tests were broken apart into two pieces plus a main program.
The main program did nothing but call a function in one of the pieces.
The test was broken apart to have as much interaction between the two
pieces as possible; for example, exception handling tests had a throw
in one piece and the catch in another.  Each piece was built into 
either a relocatable object file, a static library, or a shared object,
one piece compiled by each of the compilers.  They were then linked with
the main program and the test was run.

These tests were a pain to set up, even for testing one compiler on one
platform with one operating system.  They required either building
object files with older compilers ahead of time and then using those
archived files when testing the new compiler, or else having both old
and new compilers available when running the tests.  I'm not at all sure
how to set up such tests for use with GCC.  The test harness needs to
know about two compilers under test rather than one, and the tests need
to build static and shared libraries, which GCC tests don't normally do.
I don't know how difficult it is with either DejaGNU or QMTest to handle
either of these, but if there's interest I'll look into it.

I've attached, as a dummy patch, a shell script that demonstrates this
kind of test plus source files for two sample tests.

Janis Johnson
IBM Linux Technology Center


--- empty	Mon Aug 12 16:37:10 2002
+++ compat.sh	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,242 @@
+#! /bin/sh
+
+########################################################################
+#
+# Test compatibility of two compilers that follow the same ABI.
+#
+# Each test has a main program that does nothing but call a function,
+# plus two additional source files that contain parts of a program that
+# rely on the ABI.  Those source files are compiled into relocatable
+# object files, static libraries, and shared objects with both
+# compilers.  Executables are built using various combinations of those
+# object files, with the main program compiled with the new compiler
+# and using the new compiler's runtime support.
+#
+# This kind of testing can also detect duplicate or missing symbols for
+# various kinds of object files, even using the same compiler.
+#
+# This is meant to be an example of this kind of compatibility testing.
+#
+#
+# Copyright (c) 2002 Free Software Foundation.
+#
+# This file is part of GNU CC.
+#
+# GNU CC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# GNU CC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU CC; see the file COPYING.  If not, write to
+# the Free Software Foundation, 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+#
+########################################################################
+
+if [ "x${NEWCPP}" = x ]; then
+  echo "$0: NEWCPP must be the new C++ compiler to test"
+  exit 1
+fi
+
+if [ "x${OLDCPP}" = x ]; then
+  echo "$0: OLDCPP must be the old C++ compiler to test"
+  exit 1
+fi
+
+if [ "x${NEWLIBPATH}" = x ]; then
+  echo "$0: NEWLIBPATH must be the lib directory for the new C++ compiler"
+  exit 1
+fi
+
+if [ "x${OLDLIBPATH}" = x ]; then
+  echo "$0: OLDLIBPATH must be the lib directory for the old C++ compiler"
+  exit 1
+fi
+
+LIB_PATH=${NEWLIBPATH}:${OLDLIBPATH}:.
+
+if [ $# -eq 0 ]; then
+  echo "Usage: $0 testname ..."
+  exit 1
+fi
+
+# Build a single relocatable object file.  Warn if it doesn't build; the
+# tests that use it will fail when they don't link.
+
+build_o ()
+{
+  CPP="$1"
+  OBJ=$2
+  SRC=$3
+
+  ${CPP} -c -o ${OBJ} ${SRC}
+  if [ $? -ne 0 ]; then
+    echo "WARNING: ${TESTNAME}: could not build ${OBJ}"
+  fi
+}
+
+# Build all needed relocatable object files.
+
+build_all_o ()
+{
+  SRC_MAIN=${TESTNAME}_main.C
+  SRC_X=${TESTNAME}_x.C
+  SRC_Y=${TESTNAME}_y.C
+
+  build_o ${NEWCPP} main.o ${SRC_MAIN}
+  build_o ${NEWCPP} x_new.o ${SRC_X}
+  build_o ${NEWCPP} y_new.o ${SRC_Y}
+  build_o ${OLDCPP} x_old.o ${SRC_X}
+  ${OLDCPP} -c -o y_old.o ${SRC_Y}
+}
+
+# Build a single static library.  Warn if it doesn't build; the tests
+# that use it will fail when they don't link.
+
+build_a ()
+{
+  LIB=$1
+  OBJ=$2
+
+  ar cq ${LIB} ${OBJ}
+  if [ $? -ne 0 ]; then
+    echo "WARNING: ${TESTNAME}: could not build ${LIB}"
+  fi
+}
+
+# Build static libraries.  This assumes the relocatable object files
+# have already been built.
+
+build_all_a ()
+{
+  build_a libx_new_a.a x_new.o
+  build_a liby_new_a.a y_new.o
+  build_a libx_old_a.a x_old.o
+  build_a liby_old_a.a y_old.o
+}
+
+# Build a single shared object file.  Warn if it doesn't build; the tests
+# that use it will fail when they don't link.
+
+build_so ()
+{
+  CPP=$1
+  SO=$2
+  SRC=$3
+
+  ${CPP} -fPIC -shared -o ${SO} ${SRC}
+  if [ $? -ne 0 ]; then
+    echo "WARNING: ${TESTNAME}: could not build ${SO}"
+  fi
+}
+
+# Build all needed shared object files.
+
+build_all_so ()
+{
+  SRC_MAIN=${TESTNAME}_main.C
+  SRC_X=${TESTNAME}_x.C
+  SRC_Y=${TESTNAME}_y.C
+
+  build_so ${NEWCPP} libx_new_so.so ${SRC_X}
+  build_so ${NEWCPP} liby_new_so.so ${SRC_Y}
+  build_so ${OLDCPP} libx_old_so.so ${SRC_X}
+  build_so ${OLDCPP} liby_old_so.so ${SRC_Y}
+}
+
+clean()
+{
+  rm -rf *.o *.a *.so a.out
+}
+
+# Link the program using a combination of object file types and then
+# run the resulting executable.  Report failure or success.
+
+link_and_go()
+{
+  ARGS="$1"
+  LD_LIBRARY_PATH=${LIB_PATH} ${NEWCPP} -L. -o a.out main.o $ARGS
+  if [ $? -ne 0 ]; then
+    echo "FAIL (link): $TESTNAME: $ARGS"
+  else
+    LD_LIBRARY_PATH=${LIB_PATH} ./a.out
+    if [ $? -ne 0 ]; then
+      echo "FAIL (run): $TESTNAME: $ARGS"
+    else
+      echo "PASS: $TESTNAME: $ARGS"
+    fi
+  fi
+}
+
+do_test ()
+{
+  # Build the object files that will be used for the tests.
+
+  build_all_o
+  build_all_a
+  build_all_so
+
+  # Build using combinations of .o, .a, and .so files that were all built
+  # with the new compiler.
+
+  link_and_go "x_new.o y_new.o"
+  link_and_go "x_new.o -ly_new_a"
+  link_and_go "x_new.o -ly_new_so"
+  link_and_go "-lx_new_a y_new.o"
+  link_and_go "-lx_new_a -ly_new_a"
+  link_and_go "-lx_new_a -ly_new_so"
+  link_and_go "-lx_new_so y_new.o"
+  link_and_go "-lx_new_so -ly_new_a"
+  link_and_go "-lx_new_so -ly_new_so"
+
+  # Build, linking with the new compiler, an executable that uses a
+  # .o, .a, or .so compiled with the new compiler and a .a or .so built
+  # using a compatible compiler.
+  #
+  # Should relocatable object files from the old compiler be supported,
+  # or only libraries?
+
+  link_and_go "x_new.o y_old.o"
+  link_and_go "x_new.o -ly_old_a"
+  link_and_go "x_new.o -ly_old_so"
+  link_and_go "-lx_new_a y_old.o"
+  link_and_go "-lx_new_a -ly_old_a"
+  link_and_go "-lx_new_a -ly_old_so"
+  link_and_go "-lx_new_so y_old.o"
+  link_and_go "-lx_new_so -ly_old_a"
+  link_and_go "-lx_new_so -ly_old_so"
+
+  # Same as the previous set of executables, but change the order of which
+  # piece is compiled with which compiler.
+
+  link_and_go "x_old.o y_new.o"
+  link_and_go "x_old.o -ly_new_a"
+  link_and_go "x_old.o -ly_new_so"
+  link_and_go "-lx_old_a y_new.o"
+  link_and_go "-lx_old_a -ly_new_a"
+  link_and_go "-lx_old_a -ly_new_so"
+  link_and_go "-lx_old_so y_new.o"
+  link_and_go "-lx_old_so -ly_new_a"
+  link_and_go "-lx_old_so -ly_new_so"
+
+  clean
+}
+
+# Process each test specified on the command line.
+
+for TESTNAME
+do
+  if [ ! -f ${TESTNAME}_main.C \
+      -o ! -f ${TESTNAME}_x.C \
+      -o ! -f ${TESTNAME}_y.C ]; then
+    echo "ERROR: ${TESTNAME}: one or more test files does not exist"
+  else
+    do_test
+  fi
+done
--- empty	Mon Aug 12 16:37:10 2002
+++ bitfield_main.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,11 @@
+// Test for an incompatible ABI change that was made between GCC 3.1.1
+// and GCC 3.2.  This test is expected to fail for compilers that span
+// that version change.
+
+extern void bitfield_x (void);
+
+int
+main ()
+{
+  bitfield_x ();
+}
--- empty	Mon Aug 12 16:37:10 2002
+++ bitfield_x.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,17 @@
+struct S {
+  char a;
+  int b : 224;
+  char c;
+};
+
+extern void bitfield_y (S);
+
+void
+bitfield_x ()
+{
+  S s;
+  s.a = 'a';
+  s.b = 1234;
+  s.c = 'c';
+  bitfield_y (s);
+}
--- empty	Mon Aug 12 16:37:10 2002
+++ bitfield_y.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,18 @@
+struct S {
+  char a;
+  int b : 224;
+  char c;
+};
+
+extern "C" void abort ();
+extern "C" void exit (int);
+
+void
+bitfield_y (S s)
+{
+  if (s.a != 'a'
+      || s.b != 1234
+      || s.c != 'c')
+    abort ();
+  exit (0);
+}
--- empty	Mon Aug 12 16:37:10 2002
+++ filter1_main.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,11 @@
+// Test that cleanups get run when a catch filter fails to match,
+// derived from g++.dg/eh/filter1.C to test compatibility between
+// different compiler versions.
+
+extern void ex_test_x (void);
+
+int
+main ()
+{
+  ex_test_x ();
+}
--- empty	Mon Aug 12 16:37:10 2002
+++ filter1_x.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,22 @@
+extern "C" void abort();
+
+struct a
+{
+  a();
+  ~a();
+};
+
+extern void ex_test_y (void);
+
+void
+ex_test_x ()
+{
+  try
+    {
+      ex_test_y ();
+    }
+  catch (...)
+    {
+    }
+  abort ();
+}
--- empty	Mon Aug 12 16:37:10 2002
+++ filter1_y.C	Mon Aug 12 16:37:10 2002
@@ -0,0 +1,26 @@
+extern "C" void exit(int);
+
+struct a
+{
+  a();
+  ~a();
+};
+
+struct e1 {};
+struct e2 {};
+
+void
+ex_test_y ()
+{
+  a aa;
+  try
+    {
+      throw e1 ();
+    }
+  catch (e2 &)
+    {
+    }
+}
+
+a::a() { }
+a::~a() { exit (0); }

Re: GCC 3.2

[Jeff Law]

 In message < 20020812164321.A4428@us.ibm.com >, Janis Johnson writes:
 >There are many things that can break compatibility between two releases
 >of a C++ compiler or between two different compilers that are expected
 >to be binary compatible.
Certainly.  

 > In a previous position I set up some tests to
 >help detect such breakage between one release and another.  They
 >occasionally found things like entry points that were thought to no
 >longer be needed in runtime support libraries, or conflicts between
 >symbols in shared objects.  These were tests of compatibility for the
 >compiler and its run-time support, not for functionality within the
 >Standard C++ Library.
Right.  That's one of the reasons why I mentioned in an earlier message
that we need a test which verifies that all of the exported functions
in libstdc++ (and libgcc) are maintained over time -- which has the
side effect of being a reasonable tester for name mangling changes.
We need ways to verify structure layouts aren't changing, etc etc.


 >Existing tests were broken apart into two pieces plus a main program.
Yes.  We had something like this in very old versions of c-torture (before
we moved to the dejagnu framework).  It was never populated with very
many tests and nobody ever wrote a suitable dejagnu framework so that
we could use those tests.

At the time when we brought c-torture into the dejagnu framework I
briefly poked at building a harness which would work for those tests,
but ultimately dropped the project due to lack of time.

 >These tests were a pain to set up, even for testing one compiler on one
 >platform with one operating system. 
Most definitely!

 >and new compilers available when running the tests.  I'm not at all sure
 >how to set up such tests for use with GCC.  The test harness needs to
 >know about two compilers under test rather than one, and the tests need
 >to build static and shared libraries, which GCC tests don't normally do.
 >I don't know how difficult it is with either DejaGNU or QMTest to handle
 >either of these, but if there's interest I'll look into it.
The existing harness for dejagnu doesn't currently know how to do this,
it's something that we definitely need though, along with shared library
support.

jeff
 

Re: GCC 3.2

[Phil Edwards]

On Tue, Aug 13, 2002 at 10:49:46AM -0600, Jeff Law wrote:
> Right.  That's one of the reasons why I mentioned in an earlier message
> that we need a test which verifies that all of the exported functions
> in libstdc++ (and libgcc) are maintained over time -- which has the
> side effect of being a reasonable tester for name mangling changes.
> We need ways to verify structure layouts aren't changing, etc etc.


In message < 20020812164321.A4428@us.ibm.com >, Janis Johnson writes:
> >and new compilers available when running the tests.  I'm not at all sure
> >how to set up such tests for use with GCC.  The test harness needs to
> >know about two compilers under test rather than one,


For some time now my nightly autocrasher[*] has built both the current trunk
and the current 3.whatever-the-previous-release-was branch.  I've started
comparing exported symbol information from the libstdc++.so's from both
builds.  (See the libstdc++ list archives of the last week or so; posts
from Benjamin and Ulrich and myself.)

I've verified that changing the size of an exported symbol triggers the
regression detection.  Work yet to be done:

1)  Test for layout changes, not just size changes.

2)  Find a way of putting this into the v3 repository.

I've no ideas on (1).  For (2) I'll be posting some thoughts on the v3
list later.


Phil
[*] "autobuilder" is just too positive and uplifing a name for something as
    hacky as what I wrote.

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: GCC 3.2

[Benjamin Kosnik]

Just an update for those not monitoring the libstdc++ list.

There's been a discussion of this, and a partial implementation by
Ulrich, Phil, and myself. It looks like initial implementation is here

http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html

Please comment if there are any bright ideas on how to make this better.

thanks,
benjamin

Re: GCC 3.2

[Kevin B. Hendricks]

Hi,,

As is will your tests detect any layout issues (changes in sizeof and 
offsetof of structure members) like the datatest.cxx, I abstracted from 
OOo code and sent to Franz?  It was those changes from gcc 2.95.X to gcc 
3.X that made the C++ to uno bridge codeneed to use an alignment 
workaround.

Thanks,

Kevin


On August 21, 2002 12:31, Benjamin Kosnik wrote:
> Just an update for those not monitoring the libstdc++ list.
>
> There's been a discussion of this, and a partial implementation by
> Ulrich, Phil, and myself. It looks like initial implementation is here
>
> http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html
>
> Please comment if there are any bright ideas on how to make this better.
>
> thanks,
> benjamin

Re: GCC 3.2

[Benjamin Kosnik]

> As is will your tests detect any layout issues (changes in sizeof and 
> offsetof of structure members) like the datatest.cxx, I abstracted from 
> OOo code and sent to Franz?  It was those changes from gcc 2.95.X to gcc 
> 3.X that made the C++ to uno bridge codeneed to use an alignment 

No. currently it only checks for added/removed symbols and object size.
Can you please send me your test file datatest.cxx..

The goal is to get basic ABI stuff in now, and then the sizeof/alignof
bits can go in at a later date.

-benjamin

Re: GCC 3.2

[Kevin B. Hendricks]

Hi,

Atttached is a datatest.cxx file I abstracted from code that does this in 
the cppu module of OpenOffice.org.  I am not the original author of the 
code (I just pulled it into a standalone version to ease testing).  The 
code is LGPL'd so it should be fine for inclusion if you want it.

Under gcc 2.95.X compile with 
g++ -O2 -odatatest datatest.cxx
./datatest

Under gcc 3.X compile with
g++ -DADJUST_ALIGN -O2 -odatatest datatest.cxx
./datatest

It was not meant to necessarily show problems.  It was meant to detect 
changes from gcc 2.95.X to gcc 3.X that would impact OpenOffice.org C++ to 
UNO component bridging code.

Hope this helps,

Kevin



On August 21, 2002 12:49, Benjamin Kosnik wrote:
> > As is will your tests detect any layout issues (changes in sizeof and
> > offsetof of structure members) like the datatest.cxx, I abstracted
> > from OOo code and sent to Franz?  It was those changes from gcc 2.95.X
> > to gcc 3.X that made the C++ to uno bridge codeneed to use an
> > alignment
>
> No. currently it only checks for added/removed symbols and object size.
> Can you please send me your test file datatest.cxx..
>
> The goal is to get basic ABI stuff in now, and then the sizeof/alignof
> bits can go in at a later date.
>
> -benjamin

Re: GCC 3.2

[Janis Johnson]

On Tue, Aug 20, 2002 at 09:31:15PM -0700, Benjamin Kosnik wrote:
> 
> Just an update for those not monitoring the libstdc++ list.
> 
> There's been a discussion of this, and a partial implementation by
> Ulrich, Phil, and myself. It looks like initial implementation is here
> 
> http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html
> 
> Please comment if there are any bright ideas on how to make this better.

Benjamin,

You are focusing on libstdc++ testing rather than compiler and runtime
support, is that correct?

I've been trying to summarize what needs to be tested and what
approaches can be used for that testing, with the goal of figuring out
which part of this I can help with.  Here are my notes, based on your
document at http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt , the C++
ABI, Intel's C++ ABI test suite, the LSB mail archives and FAQ, and
messages from several people in the GCC mailing lists.

Janis


Things to test

  compiler and runtime support covered by the C++ ABI:
    data layout
      layout of class and structure elements
      alignment of variables
      pointer to data member
      pointer to member function
      virtual table layout and alignment
      array operator "new" cookies
      initialization guard variables
      run-time type information (RTTI)
    function calling conventions and APIs
      stack unwind
      argument passing
      virtual function
      demangler API
      constructor and destructor APIs
    exception handling interfaces
    linkage and object files
      name mangling
      linkage of inline functions, vtables
      unwind table location
    other
      template instantiation
      runtime arithmetic support

  C++ Standard Library:
    namespaces
    sizes and layout of externally visible classes and structures
    signatures of externally visible functions

outside the scope of GCC testing efforts:

  cross-platform testing (including different releases of the same OS)
  testing with different linkers and/or dynamic linkers
  startup files?

Approaches to testing C++ and libstdc++ compatibility, ABI conformance

libstdc++ consistency
  http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html

  covers:
    libstdc++ consistency from release to release

  advantages:

  disadvantages:

Intel's C++ ABI test suite:
  http://developer.intel.com/software/products/opensource/

  covers:
    compiler and runtime support covered by the C++ ABI

  advantages:
    exists, available

  disadvantages:
    limited to IA-64?
    large granularity for failures

gcc/testsuite/consistency.vlad
  covers:
    layout of class and structure elements

  advantages:
    already exists
    fits into the existing GCC testsuite

  disadvantages:
    need to establish a baseline for each platform

LSB conformance test suite
  covers:
    not sure yet

  advantages:
    will be developed by the LSB team

  disadvantages:
    only applies to platforms covered by the LSB

gdb test suite (suggested by Jim Wilson)
  covers (indirectly):
    layout of structure elements
    argument passing
    vtable layout
    name mangling

  advantages:
    easy to use for anyone who runs the GCC testsuite
    available on many platforms (anywhere gdb is available)

  disadvantages:
    can't be used on platforms where gdb isn't available

GCC test suites with different version of libstdc++
  covers:
    compiler and runtime support used by libstdc++
    libstdc++ consistency from release to release

  advantages:
    easy to set up

  disadvantages:
    need to recognize test failures due to changes in the test suite

special-purpose self-checking tests in GCC testsuite
  covers:
    whatever we want

  advantages:
    part of every testsuite run

  disadvantages:
    limited to what the testsuite supports: single file per test, no
    shared libraries, use of a single compiler

split tests to compile pieces with two compilers
  http://gcc.gnu.org/ml/gcc/2002-08/msg00712.html

  covers:
    anything for the compiler and runtime support library

  advantages:
    has the potential to uncover unexpected problems that wouldn't be
    detected by other testing

  disadvantages:
    doesn't yet exist

    won't easily fit into the GCC testsuite
      need to have two compilers available when tests are run or else
      save baseline object files for each platform (.o, .so, .a)

      building static libraries and shared objects is OS-dependent

Glossary

  C++ ABI: An Application Binary Interface for C++ programs that was
    designed to be specific to 64-bit Itanium but that also includes
    generic specifications that apply to any platform.  See
    http://www.codesourcery.com/cxx-abi/ .

  libstdc++ ABI: There is no formal specification of this, it's just
    how the library is actually implemented.

  LSB: The Linux Standards Base specifies binary interfaces that allow
    compliant applications to run on a variety of conforming GNU/Linux
    distributions.  See http://www.linuxbase.org/FAQ.html .

  ABI conformance: compiler or library is implemented according to an
    ABI, or application is built using only tools that conform to a set
    of ABIs

  compatibility: two different compilers, or two versions of the same
    compiler, generate object files that can be linked together

  consistency: the same compiler does the same thing from one release to
    another

  interoperability: ability to link relocatable objects built by
    different compilers that conform to the same C++ ABI and that were
    built using header files for the same or compatible implementations
    of the C++ Standard Library

Re: GCC 3.2

[Phil Edwards]

On Wed, Aug 21, 2002 at 11:25:07AM -0700, Janis Johnson wrote:
> You are focusing on libstdc++ testing rather than compiler and runtime
> support, is that correct?

Not speaking for Benjmain but:  yes, mostly, that's my understanding.
But of course changes in the latter could show up while testing the former.

We're /explicitly/ testing the former.  I think the expectation is that
explicit tests for the latter should go into the compiler testsuite.
(And we'll try to help, of course; the division is not so much "who does
the work" but rather "where does the work go".)


   >   compiler and runtime support covered by the C++ ABI:
   >     data layout
   >       layout of class and structure elements
   >       alignment of variables
   >       pointer to data member
   >       pointer to member function
   >       virtual table layout and alignment
   >       array operator "new" cookies
   >       initialization guard variables
   >       run-time type information (RTTI)
   >     function calling conventions and APIs
   >       stack unwind
   >       argument passing
   >       virtual function
   >       demangler API
   >       constructor and destructor APIs
   >     exception handling interfaces
   >     linkage and object files
*  >       name mangling
*  >       linkage of inline functions, vtables
   >       unwind table location
   >     other
*  >       template instantiation
   >       runtime arithmetic support
   > 
   >   C++ Standard Library:
*  >     namespaces
*  >     sizes and layout of externally visible classes and structures
*  >     signatures of externally visible functions

We are working on '*' as we speak.  (Perhaps not the linkage of inline
functions, and layout tests are currently not done.  But vtables and sizes
are.  Well, I /know/ sizes are tested, and I /think/ vtables are tested.)


> Approaches to testing C++ and libstdc++ compatibility, ABI conformance
> 
> libstdc++ consistency
>   http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html
> 
>   covers:
>     libstdc++ consistency from release to release
> 
>   advantages:
      Exists as of a couple hours ago...

>   disadvantages:
      Looks like we're going to need to gather more per-OS/-per-CPU
      baseline data than what we originally thought.  Help solicited.


> special-purpose self-checking tests in GCC testsuite
>   covers:
>     whatever we want
> 
>   advantages:
>     part of every testsuite run
> 
>   disadvantages:
>     limited to what the testsuite supports: single file per test, no
>     shared libraries, use of a single compiler

No shared libraries?  I know for a fact that if I accidentally move the
libstdc++.so out of the way, all the testsuite fails when the runtime
loader can't satisfy the dependancies.


> split tests to compile pieces with two compilers
>   http://gcc.gnu.org/ml/gcc/2002-08/msg00712.html
> 
>   covers:
>     anything for the compiler and runtime support library
> 
>   advantages:
>     has the potential to uncover unexpected problems that wouldn't be
>     detected by other testing
> 
>   disadvantages:
>     doesn't yet exist
> 
>     won't easily fit into the GCC testsuite
>       need to have two compilers available when tests are run or else
>       save baseline object files for each platform (.o, .so, .a)
> 
>       building static libraries and shared objects is OS-dependent

I might just have a go at this.  Right now I've automated the "test both
branches, swap the .so's, test both branches again" test that people tried
just before the 3.2 release.  So the two-compilers problem is solved.


This document is extraordinarily helpful.  Thanks!

Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: GCC 3.2

[Janis Johnson]

On Wed, Aug 21, 2002 at 03:02:34PM -0400, Phil Edwards wrote:
> On Wed, Aug 21, 2002 at 11:25:07AM -0700, Janis Johnson wrote:
> > You are focusing on libstdc++ testing rather than compiler and runtime
> > support, is that correct?
> 
> Not speaking for Benjmain but:  yes, mostly, that's my understanding.
> But of course changes in the latter could show up while testing the former.

Yes, they are all interconnected.

> We're /explicitly/ testing the former.  I think the expectation is that
> explicit tests for the latter should go into the compiler testsuite.
> (And we'll try to help, of course; the division is not so much "who does
> the work" but rather "where does the work go".)

Yes; I just wanted to make sure that I understood your main focus.

> 
> > Approaches to testing C++ and libstdc++ compatibility, ABI conformance
> > 
> > libstdc++ consistency
> >   http://gcc.gnu.org/ml/libstdc++/2002-08/msg00190.html
> > 
> >   covers:
> >     libstdc++ consistency from release to release
> > 
> >   advantages:
>       Exists as of a couple hours ago...
> 
> >   disadvantages:
>       Looks like we're going to need to gather more per-OS/-per-CPU
>       baseline data than what we originally thought.  Help solicited.
> 
> 
> > special-purpose self-checking tests in GCC testsuite
> >   covers:
> >     whatever we want
> > 
> >   advantages:
> >     part of every testsuite run
> > 
> >   disadvantages:
> >     limited to what the testsuite supports: single file per test, no
> >     shared libraries, use of a single compiler
> 
> No shared libraries?  I know for a fact that if I accidentally move the
> libstdc++.so out of the way, all the testsuite fails when the runtime
> loader can't satisfy the dependancies.

What I meant is that I know of no provision for a test to build and use
a shared library that is part of the test itself.

> 
> > split tests to compile pieces with two compilers
> >   http://gcc.gnu.org/ml/gcc/2002-08/msg00712.html
> > 
> >   covers:
> >     anything for the compiler and runtime support library
> > 
> >   advantages:
> >     has the potential to uncover unexpected problems that wouldn't be
> >     detected by other testing
> > 
> >   disadvantages:
> >     doesn't yet exist
> > 
> >     won't easily fit into the GCC testsuite
> >       need to have two compilers available when tests are run or else
> >       save baseline object files for each platform (.o, .so, .a)
> > 
> >       building static libraries and shared objects is OS-dependent
> 
> I might just have a go at this.  Right now I've automated the "test both
> branches, swap the .so's, test both branches again" test that people tried
> just before the 3.2 release.  So the two-compilers problem is solved.

This approach uses two compilers to build pieces of a single test which
are then linked together and run.  Is that problem solved?

> This document is extraordinarily helpful.  Thanks!

Then I'll keep updating it.  Would this be useful as part of the
projects list while we figure out what needs to be done?

Janis

Re: GCC 3.2

[Benjamin Kosnik]

> > > split tests to compile pieces with two compilers
> > >   http://gcc.gnu.org/ml/gcc/2002-08/msg00712.html
> > > 
> > >   covers:
> > >     anything for the compiler and runtime support library
> > > 
> > >   advantages:
> > >     has the potential to uncover unexpected problems that wouldn't be
> > >     detected by other testing
> > > 
> > >   disadvantages:
> > >     doesn't yet exist
> > > 
> > >     won't easily fit into the GCC testsuite
> > >       need to have two compilers available when tests are run or else
> > >       save baseline object files for each platform (.o, .so, .a)
> > > 
> > >       building static libraries and shared objects is OS-dependent
> > 
> > I might just have a go at this.  Right now I've automated the "test both
> > branches, swap the .so's, test both branches again" test that people tried
> > just before the 3.2 release.  So the two-compilers problem is solved.
> 
> This approach uses two compilers to build pieces of a single test which
> are then linked together and run.  Is that problem solved?

Phil seems to be working on it. I noticed you also posted a shell script
to do it. At some point this should be spelled out and put in the docs.

> > This document is extraordinarily helpful.  Thanks!
> 
> Then I'll keep updating it.  Would this be useful as part of the
> projects list while we figure out what needs to be done?

Yes. You can add it to libstdc++-v3/docs/html/abi.txt if you'd like.

Thanks!
benjamin