C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik]

I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
same C++ ABI before gcc-3.2 is released.

As far as I know, there is no official ABI testing as per the release
process. Several people have suggested ways to test this. A summary is
here:

http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt

Under: 

IV. Testing ABI changes

[snip]

One. 
(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
one with a new compiler and an old library, and the other with an old
compiler and a new library, and look for testsuite regressions)


I did this last night, and unfortunately cannot say that this approach
is currently working with gcc and gcc-3_2-branch C++ binaries. 

Here are my results, which are tenative. I'm re-running these, as I
started this too late last night to really be sure.

I'd apprecaite it if somebody could verify my results.

3.2 libstdc++.so.5 in a 3.3 build directory, make check == 0K
3.3 libstdc++.so.5 in a 3.2 build directory, make check == 15 FAILS

FAIL: 19_diagnostics/stdexceptions.cc execution test
FAIL: 21_strings/append.cc execution test
FAIL: 21_strings/ctor_copy_dtor.cc execution test
FAIL: 21_strings/element_access.cc execution test
FAIL: 21_strings/insert.cc execution test
FAIL: 21_strings/substr.cc execution test
FAIL: 22_locale/ctor_copy_dtor.cc execution test
FAIL: 23_containers/bitset_ctor.cc execution test
FAIL: 23_containers/bitset_members.cc execution test
FAIL: 23_containers/list_modifiers.cc execution test
FAIL: 23_containers/vector_element_access.cc execution test
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess
errors)
FAIL: 27_io/ios_base_storage.cc execution test
FAIL: 27_io/ios_init.cc execution test
FAIL: 27_io/ios_members.cc execution test

		=== libstdc++-v3 Summary ===

# of expected passes		394
# of unexpected failures	15
# of unexpected successes	26


Debugging the first of these... 

/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/g++ -shared-libgcc
-B/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/ -nostdinc++
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
/.libs -B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/include -g
-ffunction-sections -fdata-sections -fmessage-length=0 -DDEBUG_ASSERT
-DLOCALEDIR="/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libst
dc++-v3/po/share/locale" -nostdinc++
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude/i686-pc-linux-gnu
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude -I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libsupc++
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libio
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/include/backward
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc -DDEBUG_ASSERT -lm -o ./stdexceptions.exe

%ldd stdexceptions.exe 
	libstdc++.so.5 =>
/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src/.
libs/libstdc++.so.5 (0x40015000)
	libm.so.6 => /lib/i686/libm.so.6 (0x400d7000)
	libgcc_s.so.1 => /mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/libgcc_s.so.1
(0x400f9000)
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

looks ok

%./stdexceptions.exe 
Abort (core dumped)

(gdb) where
#0  0x42029241 in kill () from /lib/i686/libc.so.6
#1  0x4202902a in raise () from /lib/i686/libc.so.6
#2  0x4202a7d2 in abort () from /lib/i686/libc.so.6
#3  0x400b1407 in __cxxabiv1::__terminate(void (*)()) (
    handler=0x4202a664 <abort>)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x400b1444 in std::terminate() ()
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x400b15c6 in __cxa_throw (obj=0x804b788, tinfo=0x0, dest=0)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_throw.cc:77
#6  0x08049198 in test03() ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:62
#7  0x0804958f in main ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:110
#8  0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

stepping through it, get to __cxa_throw in eh_thow.cc, line 72:

  // Some sort of unwinding error.  Note that terminate is a handler.
  __cxa_begin_catch (&header->unwindHeader);
  std::terminate ();

Ouch. Isn't this a case of exception regions being screwed?

-benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Matt Austern]

On Friday, August 2, 2002, at 09:16 AM, Benjamin Kosnik wrote:

> I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
> same C++ ABI before gcc-3.2 is released.
>
> As far as I know, there is no official ABI testing as per the release
> process. Several people have suggested ways to test this.

An ABI test suite is a good idea.  Ultimately, of course, the real
test is the one users care about: can I generate a DSO (or, more
generally, an object file) with an old compiler, and link it to
something generated with the new compiler?  That's the whole
point of ABI stability.

But I'm not sure this really addresses the main problem.  A test
suite will make sure there aren't any accidental ABI changes.  But
has that actually been a problem?  Seems to me that the real
3.1/3.2 issue is intentional ABI changes: fixing ABI-related bugs in
3.1.  The question is whether we'll find more bugs in 3.2, and make
intentional changes to fix them for 3.3.

Preventing intentional ABI changes is less a technical issue than
a management decision.  Look at how Sun has maintained a
stable C++ ABI, for example.  Mostly it's because they made two
decisions, and made a commitment to stick to them:
  1. They decided that ABI stability was more important than
      correctness.  They decided that they will not fix certain kinds
      of bugs, if bug fixes would break compatibility.
  2. They decided that they would not release a compiler with
      something that they called a frozen ABI until they'd tested it
      thoroughly enough that they'd be sure there weren't  many
      such bugs.

(My guess is they also made a third unannounced decision:
that if they ever do introduce a new ABI it will be as an addition,
not a replacement, and that they will never stop shipping a
compiler that supports the current ABI.)

My impression is that we're not yet ready to make decision #1, that
at this point we still think correctness is more important than
stability.  I also don't have the impression that we're ready yet to
make decision #2; I don't think anyone wants to delay the 3.2 release
for six months worth of testing.  Am I right about both of those
impressions?

				--Matt

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik]

> But I'm not sure this really addresses the main problem.  A test
> suite will make sure there aren't any accidental ABI changes.  But
> has that actually been a problem? 

It is my contention that this is a real problem that is currently an
active issue for the gcc-3_2-branch.

There does not seem to be consensus about this. I'm looking for
clarification. If gcc-3.3 and gcc-3.2 are going to diverge right at the
onset, a series of versioning bits will also have to be modified to make
the difference explicit.

I am of the opinion that gcc-3.2 and gcc-3.3 should strive for the same
ABI. If, at some point before gcc-3.3 is released, yet after 3.2 is
released, it is broken, well then. I consider that a different issue.

So, in summary, I'm getting at:

1) I would think that gcc-3.2 and gcc-3.3 should match C++ ABI's at the
point where gcc-3.2 is released. I don't believe they do, but may be
wrong. I'm looking for some help in testing.

2) Ff the released gcc-3.3 will match the released gcc-3.2's ABI is a
decision that can be put off until the gcc-3.3 release process kicks
into gear. In any case, it is a decision that should be explicitly made,
and backed up with some kind of testing.

> Seems to me that the real
> 3.1/3.2 issue is intentional ABI changes: fixing ABI-related bugs in
> 3.1.  The question is whether we'll find more bugs in 3.2, and make
> intentional changes to fix them for 3.3.

It seems likely that more ABI bugs will be encountered after 3.2 is
released. I don't say that lightly, and know how hard everybody is
working on this issue. 

Changing the ABI yet again must be planned. If it doesn't have to be
done, cool. If so, then every developer will know when/what is possible.

> Preventing intentional ABI changes is less a technical issue than
> a management decision.  Look at how Sun has maintained a
> stable C++ ABI, for example.  Mostly it's because they made two
> decisions, and made a commitment to stick to them:

There are two, distinct issues. One: can I verify that a given change,
or two different compilers, have the same ABI? If not, can I see where
they diverge?

There is no testing plan in place.

After this is known, not guessed at, then the second issue is as you
described: when is the ABI broken, and what is the longer term plan.

I think resolving the first issue is of major important at the moment.

-benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Joe Buck]

Matt Austern writes:
> An ABI test suite is a good idea.  Ultimately, of course, the real
> test is the one users care about: can I generate a DSO (or, more
> generally, an object file) with an old compiler, and link it to
> something generated with the new compiler?  That's the whole
> point of ABI stability.

The GNU C++ policy up to this point has been to insist at least that
minor releases be binary-compatible, for both the compiler and the
standard library.  We've been working towards freezing things on
larger scales as well.

> Preventing intentional ABI changes is less a technical issue than
> a management decision.  Look at how Sun has maintained a
> stable C++ ABI, for example.

Ouch.  Sun has not succeeded nearly as well as your message suggests:
because of problems with their standard library implementations, in many
cases they've broken binary compatibility even with bug fix patches,
multiple times.  Projects I've been on have been burned badly by this.

>   1. They [Sun] decided that ABI stability was more important than
>       correctness.  They decided that they will not fix certain kinds
>       of bugs, if bug fixes would break compatibility.
>   2. They decided that they would not release a compiler with
>       something that they called a frozen ABI until they'd tested it
>       thoroughly enough that they'd be sure there weren't  many
>       such bugs.

I'm sure that this was their policy, but they did not execute it
completely successfully.  They were particularly bad in the 5.x
days.  I suspect that they've learned their lesson and have better
processes in place now.

> My impression is that we're not yet ready to make decision #1, that
> at this point we still think correctness is more important than
> stability.

Actually, speaking as just one SC member, I'm pretty close to making
decision #1, in the following sense: we put out gcc 3.2, and a number
of GNU/Linux and BSD distributions go to it.  Result: we have binary
compatibility across the free-OS space.  But later it turns out that we
interpreted some part of the spec differently than some other compiler
developer.  I'd be inclined to just leave it, and document the
differences, unless the bad interpretation results in code that
malfunctions.

Note that one of the 3.1.1 -> 3.2 ABI changes falls in this category: not
only does the erroneous implementation disagree with the spec, but the
result is that certain programs will malfunction.  At this point, I would
resist changes in the ABI that aren't as serious as this.

(This is the case where we derive from a POD, and put new members into
the POD's padding.  Passing a pointer to the base class to C code is
likely to result in members of the derived class getting overwritten).

But, you say, this might mean that we aren't binary compatible with some
proprietary compiler.  Maybe so, but that will just be the proprietary
compiler vendor's problem: if GNU compatibility is important to them,
the work will be on their shoulders to achieve it.  We did the best we
could.

>  I also don't have the impression that we're ready yet to
> make decision #2; I don't think anyone wants to delay the 3.2 release
> for six months worth of testing.  Am I right about both of those
> impressions?

In order to get the agreement that we have gotten, that distribution
vendors will re-unify around an official GCC release (and get rid of the
current situation with "2.96" versus egcs versus 2.95.x versus 3.0 etc),
we don't have much room to delay 3.2.  A delay would mean that people
would start using 3.1.1 for production, or doing their own patches to make
a 3.2-that-we-now-have equivalent, delaying the window for
cross-distribution C++ ABI reunification for another year at least.

So, in summary: you're right, there may be another bug in 3.2's
implementation of the ABI.  But if so, I would recommend that we respond
by just documenting the bug.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik]

>> Nope, I'm suggesting
>> --enable-threads=posix --enable-shared --enable-__cxa_atexit
>> to be the default for linux native (or linux targets including 
>> cross?).

> That has been long overdue. I don't think there should be a difference
> between native and cross here.

Ditto. I'm in support of Jakub's configuration, as above, as the default
for linux systems.

Note that the solaris build has defaulted to threaded by default for
quite some time.

-benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Joe Buck]

Benjamin Kosnik writes:
> I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
> same C++ ABI before gcc-3.2 is released.

Yes, it's important to understand that there will be MASSIVE resistance
to changing the C++ ABI very soon again after 3.2, so it will be really
bad if 3.3-pre will already break it.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Mike Stump]

On Friday, August 2, 2002, at 03:14 PM, Joe Buck wrote:

> Benjamin Kosnik writes:
>> I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
>> same C++ ABI before gcc-3.2 is released.
>
> Yes, it's important to understand that there will be MASSIVE resistance
> to changing the C++ ABI very soon again after 3.2, so it will be really
> bad if 3.3-pre will already break it.

Bear in mind, I thought the only reason to do a 3.2 release is so that 
3.3 can be compatible with it.  If it isn't then is there _any_ reason 
to do a 3.2 release?

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Joe Buck]

> On Friday, August 2, 2002, at 03:14 PM, Joe Buck wrote:
> 
> > Benjamin Kosnik writes:
> >> I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
> >> same C++ ABI before gcc-3.2 is released.
> >
> > Yes, it's important to understand that there will be MASSIVE resistance
> > to changing the C++ ABI very soon again after 3.2, so it will be really
> > bad if 3.3-pre will already break it.
> 
> Bear in mind, I thought the only reason to do a 3.2 release is so that 
> 3.3 can be compatible with it.  If it isn't then is there _any_ reason 
> to do a 3.2 release?

What I am saying is that 3.3 must be compatible with 3.2.  If there is a
discrepancy that can be fixed on either end, but if 3.2 goes out and 3.3
doesn't match, then 3.3 has to be fixed.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Nathan Sidwell]

Mike Stump wrote:
> Bear in mind, I thought the only reason to do a 3.2 release is so that
> 3.3 can be compatible with it.  If it isn't then is there _any_ reason
> to do a 3.2 release?
It is so 3.3 has a greater than zero probability of being
compatible with 3.2. I reckon the probability is still less than one.
(But you knew that anyway :)

If we didn't do a 3.2, there would be great temptation
for system vendors to produce a 3.1.1 + ABI patches themselves.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Joe Buck]

> Mike Stump wrote:
> > Bear in mind, I thought the only reason to do a 3.2 release is so that
> > 3.3 can be compatible with it.  If it isn't then is there _any_ reason
> > to do a 3.2 release?
> It is so 3.3 has a greater than zero probability of being
> compatible with 3.2. I reckon the probability is still less than one.
> (But you knew that anyway :)
> 
> If we didn't do a 3.2, there would be great temptation
> for system vendors to produce a 3.1.1 + ABI patches themselves.

Exactly, so we have limited time to do 3.2.  Hopefully the kind of testing
that Benjamin et al are doing will let us shortly iron out any issues
with 3.2-branch/trunk compatibility.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Richard Henderson]

On Fri, Aug 02, 2002 at 09:16:14AM -0700, Benjamin Kosnik wrote:
> (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
> one with a new compiler and an old library, and the other with an old
> compiler and a new library, and look for testsuite regressions)

Indeed.  For reference, what's the best way to do this?
What you want, I think, is to run the testsuite either
with an installed compiler or installed library, but I 
thought the testsuite is set up to only look in the 
current tree for both.

> 3.2 libstdc++.so.5 in a 3.3 build directory, make check == 0K
> 3.3 libstdc++.so.5 in a 3.2 build directory, make check == 15 FAILS

Ouch.  This definitely needs to be investigated post haste.


r~

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Fri, Aug 02, 2002 at 03:23:17PM -0700, Richard Henderson wrote:
> On Fri, Aug 02, 2002 at 09:16:14AM -0700, Benjamin Kosnik wrote:
> > (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
> > one with a new compiler and an old library, and the other with an old
> > compiler and a new library, and look for testsuite regressions)
> 
> Indeed.  For reference, what's the best way to do this?

Swap libstdc++-v3/src/.libs/libstdc++.so.5.0.0 binaries between built
3.2 and trunk trees before running make check?

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik]

> > > (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two
> > > ways, one with a new compiler and an old library, and the other
> > > with an old compiler and a new library, and look for testsuite
> > > regressions)
> > 
> > Indeed.  For reference, what's the best way to do this?
> 
> Swap libstdc++-v3/src/.libs/libstdc++.so.5.0.0 binaries between built
> 3.2 and trunk trees before running make check?

Exactly. What I did, which I will soon document in abi.txt, is:

1) mkdir ~/c++abitest
2) mkdir ~/c++abitest/3.2
3) mkdir ~/c++abitest/3.3
4) make a gcc (3.3) and gcc-3_2-branch (3.2) build, and run 
'make check-c++' in each to establish baselines.
5) copy the 3.3 libraries to a set directory:
  cd /mnt/hd/bld/bld-x86-gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs
  cp libstdc++.so.5.0.0 ~/c++abitest/3.3/
6) copy the 3.2 libraries to a set directory:
  cd
/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src/.
libs
  cp libstdc++.so.5.0.0 ~/c++abitest/3.2/
7) copy the 3.2 library into the 3.3 build directory, as above
8) copy the 3.3 library into the 3.2 build directory, as above
9) re-run 'make check-c++' in each build directory.


I've reproduced this again. Same stack trace as before, and binutils,
etc. are all the same. 

I'm not quite sure how to proceed, but I'd apprecaite it if first
somebody else could try to verify my results.

It looks like everything links, so I think the libstdc++ symbol
exporting is ok, but something else is wrong.

 -benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Benjamin Kosnik]

My second round results matched my first round. Both libstdc++ and g++
testsuites show additional errors, all around eh type issues, but only
for the 3_2-branch g++ with the 3.3 libstdc++.so. The other way around
resulted in no additional failures.

		=== g++ Summary ===

# of expected passes		7154
# of unexpected failures	112
# of expected failures		88
# of untested testcases		9
# of unsupported tests		3

		=== libstdc++-v3 Summary ===

# of expected passes		394
# of unexpected failures	15
# of unexpected successes	26


These results are different than Jakub's, although he also seemed to
find issues.

-benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Fri, Aug 02, 2002 at 09:16:14AM -0700, Benjamin Kosnik wrote:
> I'd apprecaite it if somebody could verify my results.

I've done 6 libstdc++ make check runs on i386-redhat-linux.
First did make bootstrap in gcc-3.2 and gcc-3.3 tree, run make check.
In both cases, there were 25 XPASSes (22_locale stuff) and 1 FAIL -
the usual 26_numerics/c99_classification_macros_c.cc.

Next step was to swap obj-i386-redhat-linux/libstdc++-v3/src/.libs/libstdc++.so.5.0.0
between the two trees and rerun make check.
In 3.2 tree with 3.3 built libstdc++.so.5 this resulted in additional:
FAIL: 27_io/filebuf_members.cc execution test
FAIL: 27_io/ifstream_members.cc execution test
WARNING: program timed out.
FAIL: 27_io/istream_unformatted.cc execution test
FAIL: 27_io/ofstream_members.cc execution test
FAIL: 27_io/ostream_inserter_other.cc execution test
FAIL: thread/pthread1.cc execution test
FAIL: thread/pthread5.cc execution test
FAIL: thread/pthread6.cc execution test

and in 3.3 tree with 3.2 built libstdc++.so.5 this ended up with:
FAIL: 27_io/filebuf_members.cc execution test
FAIL: 27_io/filebuf_virtuals.cc execution test
FAIL: 27_io/ifstream_members.cc execution test
FAIL: 27_io/istream_extractor_other.cc execution test
FAIL: 27_io/istream_seeks.cc execution test
WARNING: program timed out.
FAIL: 27_io/istream_unformatted.cc execution test
FAIL: 27_io/ofstream_members.cc execution test
FAIL: 27_io/ostream_inserter_other.cc execution test
FAIL: 27_io/ostream_seeks.cc execution test

The last step was to make clean in libstdc++-v3 and exchange gcc subdirectories
in the two trees (so that 3.2 build tree ended up with gcc 3.3 compiler and
vice versa), then run make in libstdc++-v3 followed by make check (ie.
basically built 3.2 libstdc++-v3 using g++ 3.3 and 3.3 libstdc++-v3 using
g++ 3.2. This resulted in just those 25 XPASSes and 1 26_numeric FAIL.

Which looks like that C++ compiler is (at least in the areas tested by the
testsuite) ABI compatible, while libstdc++-v3 is not.

One problem which might invalidate the above results is that 3.2 was build
from Red Hat rpm, ie. with a bunch of configure options including enabled
thread support while 3.3 build was just ../configure i386-redhat-linux.
I'll do ../configure i386-redhat-linux bootstrap on 3.2 branch and retry
the tests to make sure.

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Sat, Aug 03, 2002 at 12:36:07PM +0200, Jakub Jelinek wrote:
> The last step was to make clean in libstdc++-v3 and exchange gcc subdirectories
> in the two trees (so that 3.2 build tree ended up with gcc 3.3 compiler and
> vice versa), then run make in libstdc++-v3 followed by make check (ie.
> basically built 3.2 libstdc++-v3 using g++ 3.3 and 3.3 libstdc++-v3 using
> g++ 3.2. This resulted in just those 25 XPASSes and 1 26_numeric FAIL.

Which is an obvious thinko in this last step, because make check was run
with the same g++ as libstdc++.so.5.0.0.
I've rerun the tests after swapping back gcc directories, ie.
3.2 libstdc++ source + built with g++ 3.3 + make check run against it with g++ 3.2
3.3 libstdc++ source + built with g++ 3.2 + make check run against it with g++ 3.3
but the results were the same, ie. 25 XPASSes, 1 FAIL.

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Sat, Aug 03, 2002 at 01:05:06PM +0200, Jakub Jelinek wrote:
> On Sat, Aug 03, 2002 at 12:36:07PM +0200, Jakub Jelinek wrote:
> > The last step was to make clean in libstdc++-v3 and exchange gcc subdirectories
> > in the two trees (so that 3.2 build tree ended up with gcc 3.3 compiler and
> > vice versa), then run make in libstdc++-v3 followed by make check (ie.
> > basically built 3.2 libstdc++-v3 using g++ 3.3 and 3.3 libstdc++-v3 using
> > g++ 3.2. This resulted in just those 25 XPASSes and 1 26_numeric FAIL.
> 
> Which is an obvious thinko in this last step, because make check was run
> with the same g++ as libstdc++.so.5.0.0.
> I've rerun the tests after swapping back gcc directories, ie.
> 3.2 libstdc++ source + built with g++ 3.3 + make check run against it with g++ 3.2
> 3.3 libstdc++ source + built with g++ 3.2 + make check run against it with g++ 3.3
> but the results were the same, ie. 25 XPASSes, 1 FAIL.

I've redone all the tests with vanilla gcc-3_2-branch and vanilla HEAD both
configured by plain configure, and in this case all 6 different make check
runs gave the same result.
This begs for the question whether if libstdc++ configured with
--enable-threads=posix and configured without this are not
binary compatible, we shouldn't default to
--enable-threads=posix --enable-__cxa_atexit
for linux native builds, so that
a) all linux distributions out there create binary compatible libstdc++
b) people who build gcc themselves and forget about --enable-threads=posix
   would be binary incompatible with vendor compilers

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[H. J. Lu]

On Sat, Aug 03, 2002 at 06:41:48PM +0200, Jakub Jelinek wrote:
> On Sat, Aug 03, 2002 at 01:05:06PM +0200, Jakub Jelinek wrote:
> > On Sat, Aug 03, 2002 at 12:36:07PM +0200, Jakub Jelinek wrote:
> > > The last step was to make clean in libstdc++-v3 and exchange gcc subdirectories
> > > in the two trees (so that 3.2 build tree ended up with gcc 3.3 compiler and
> > > vice versa), then run make in libstdc++-v3 followed by make check (ie.
> > > basically built 3.2 libstdc++-v3 using g++ 3.3 and 3.3 libstdc++-v3 using
> > > g++ 3.2. This resulted in just those 25 XPASSes and 1 26_numeric FAIL.
> > 
> > Which is an obvious thinko in this last step, because make check was run
> > with the same g++ as libstdc++.so.5.0.0.
> > I've rerun the tests after swapping back gcc directories, ie.
> > 3.2 libstdc++ source + built with g++ 3.3 + make check run against it with g++ 3.2
> > 3.3 libstdc++ source + built with g++ 3.2 + make check run against it with g++ 3.3
> > but the results were the same, ie. 25 XPASSes, 1 FAIL.
> 
> I've redone all the tests with vanilla gcc-3_2-branch and vanilla HEAD both
> configured by plain configure, and in this case all 6 different make check
> runs gave the same result.
> This begs for the question whether if libstdc++ configured with
> --enable-threads=posix and configured without this are not
> binary compatible, we shouldn't default to
			^^^^^^^^^^^^^^^^^
Are you suggesting the current default for Linux is a good thing and
all Linux distributions should do same?

I have been suggesting Linux should be default to --enable-threads=posix
and --enable-shared for a long time.

> --enable-threads=posix --enable-__cxa_atexit
> for linux native builds, so that
> a) all linux distributions out there create binary compatible libstdc++
> b) people who build gcc themselves and forget about --enable-threads=posix
>    would be binary incompatible with vendor compilers
> 


H.J.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Sat, Aug 03, 2002 at 09:46:57AM -0700, H. J. Lu wrote:
> > This begs for the question whether if libstdc++ configured with
> > --enable-threads=posix and configured without this are not
> > binary compatible, we shouldn't default to
> 			^^^^^^^^^^^^^^^^^
> Are you suggesting the current default for Linux is a good thing and
> all Linux distributions should do same?

Nope, I'm suggesting
--enable-threads=posix --enable-shared --enable-__cxa_atexit
to be the default for linux native (or linux targets including cross?).

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[H. J. Lu]

On Sat, Aug 03, 2002 at 12:49:42PM -0400, Jakub Jelinek wrote:
> On Sat, Aug 03, 2002 at 09:46:57AM -0700, H. J. Lu wrote:
> > > This begs for the question whether if libstdc++ configured with
> > > --enable-threads=posix and configured without this are not
> > > binary compatible, we shouldn't default to
> > 			^^^^^^^^^^^^^^^^^
> > Are you suggesting the current default for Linux is a good thing and
> > all Linux distributions should do same?
> 
> Nope, I'm suggesting
> --enable-threads=posix --enable-shared --enable-__cxa_atexit
> to be the default for linux native (or linux targets including cross?).

That has been long overdue. I don't think there should be a difference
between native and cross here.


H.J.

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Matthias Klose]

On # Sat, 3 Aug 2002 09:55:42 -0700, H. J. Lu wrote:
> On Sat, Aug 03, 2002 at 12:49:42PM -0400, Jakub Jelinek wrote:
> > On Sat, Aug 03, 2002 at 09:46:57AM -0700, H. J. Lu wrote:
> > > > This begs for the question whether if libstdc++ configured with
> > > > --enable-threads=posix and configured without this are not
> > > > binary compatible, we shouldn't default to
> > >			 ^^^^^^^^^^^^^^^^^
> > > Are you suggesting the current default for Linux is a good thing and
> > > all Linux distributions should do same?
> > 
> > Nope, I'm suggesting
> > --enable-threads=posix --enable-shared --enable-__cxa_atexit
> > to be the default for linux native (or linux targets including cross?).

Agreed. How do other options affect compatibility?

        --with-system-zlib (affects Java only)
        --enable-long-long
        --enable-nls
        --without-included-gettext
        --enable-clocale=gnu
        --enable-c-mbchar

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

Matthias Klose <doko@cs.tu-berlin.de> writes:

> On # Sat, 3 Aug 2002 09:55:42 -0700, H. J. Lu wrote:
>> On Sat, Aug 03, 2002 at 12:49:42PM -0400, Jakub Jelinek wrote:
>> > On Sat, Aug 03, 2002 at 09:46:57AM -0700, H. J. Lu wrote:
>> > > > This begs for the question whether if libstdc++ configured with
>> > > > --enable-threads=posix and configured without this are not
>> > > > binary compatible, we shouldn't default to
>> > >			 ^^^^^^^^^^^^^^^^^
>> > > Are you suggesting the current default for Linux is a good thing and
>> > > all Linux distributions should do same?
>> > 
>> > Nope, I'm suggesting
>> > --enable-threads=posix --enable-shared --enable-__cxa_atexit
>> > to be the default for linux native (or linux targets including cross?).
>
> Agreed. How do other options affect compatibility?

Let's rearrange the flags first:

>         --with-system-zlib (affects Java only)

This one should not affect compatibility if your zlib is recent
enough (has all the needed interfaces).

>         --enable-nls
>         --without-included-gettext

These two are used to output GCC's error and warning messages in
different languages, they should not affect anything.


>         --enable-long-long
>         --enable-clocale=gnu
>         --enable-c-mbchar

These are the interesting ones ;-)

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Schwab]

Andreas Jaeger <aj@suse.de> writes:

|> Matthias Klose <doko@cs.tu-berlin.de> writes:
|> >         --enable-long-long
|> >         --enable-clocale=gnu
|> >         --enable-c-mbchar
|> 
|> These are the interesting ones ;-)

And already enabled by default (the middle one if glibc is recent enough).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Loren James Rittle]

In article <20020803184148.P20867@sunsite.ms.mff.cuni.cz> Jakub
Jelinek writes:

> This begs for the question whether if libstdc++ configured with
> --enable-threads=posix and configured without this are not
> binary compatible,

As long as one is not attempting to actually produce a threaded
program, a gcc configured with --enable-threads=posix and another
configured with --disable-threads should be link-ABI and fully
run-time compatible.  If anyone finds a bug in this area within the
libstdc++-v3 implementation, then I'd consider myself a responsible
party.

> we shouldn't default to
> --enable-threads=posix --enable-__cxa_atexit
> for linux native builds, so that
> a) all linux distributions out there create binary compatible libstdc++
> b) people who build gcc themselves and forget about --enable-threads=posix
>   would be binary incompatible with vendor compilers

As a BSD user, I don't consider myself having franchise on this
matter, but I would strongly advocate that someone from the Linux
world modernize and centralize defaults for *-*-linux* in
gcc/config.gcc...

Some <cpu>-*-linux* default to threads, some don't.

Regarding your exact question (on why you should or shouldn't default
a certain way): More ports now have --enable-threads=posix (or
whatever) encoded by default in gcc/config.gcc .  For many (but not
all) platforms, it is near-zero overhead to add --enable-threads=posix
(or whatever) since weak symbol mappings control whether mutexs are
actually used or skipped at program run-time.  This is true for
all POSIX/ELF platforms thus covering all Linux platforms, no?

Regards,
Loren
-- 
Loren J. Rittle, Principal Staff Engineer, Motorola Labs (IL02/2240)
rittle@labs.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Loren James Rittle]

In article <20020802091614.3930072f.bkoz@redhat.com> you write:
> I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
> same C++ ABI before gcc-3.2 is released.

Agreed.

> http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt

> (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
> one with a new compiler and an old library, and the other with an old
> compiler and a new library, and look for testsuite regressions)

At first I thought it was subtly different, but I think I agree that
the above test covers what users will attempt.  Under a promise of a
stable C++ ABI, users will attempt to build against 3.2 and then run
against 3.3 (or vice versa).

> [...] I'd apprecaite it if somebody could verify my results.

> 3.2 libstdc++.so.5 in a 3.3 build directory, make check == 0K
> 3.3 libstdc++.so.5 in a 3.2 build directory, make check == 15 FAILS

With 3.2 and 3.3 built this evening (using identical configuration
lines save path information), I don't see this issue on
i386-unknown-freebsd4.6.

3.2 libstdc++.so.5 (built against binutils ~2.12.1) in a 3.3 build
directory (built against binutils ~2.13), make check == 0K

3.3 libstdc++.so.5 (built against binutils ~2.12.1 on
i386-unknown-freebsd5.0!) in a 3.2 build directory (built against
binutils ~2.12.1 on i386-unknown-freebsd4.6), make check == OK

Regards,
Loren
-- 
Loren J. Rittle, Principal Staff Engineer, Motorola Labs (IL02/2240)
rittle@labs.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

RE: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Goodman, Joe]

We provide a C++ ABI test suite you can download from
http://developer.intel.com/software/products/opensource/.  Please feel free
to download and run this suite.

Joe Goodman
Intel Corporation
Software Solutions Group

The views expressed in this posting do not necessarily reflect the views of
Intel Corporation

-----Original Message-----
From: Benjamin Kosnik [mailto:bkoz@redhat.com]
Sent: Friday, August 02, 2002 9:16 AM
To: gcc@gcc.gnu.org
Cc: rth@redhat.com
Subject: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility


I think it's important to insure that gcc-3.3 and gcc-3.2 are at the
same C++ ABI before gcc-3.2 is released.

As far as I know, there is no official ABI testing as per the release
process. Several people have suggested ways to test this. A summary is
here:

http://gcc.gnu.org/onlinedocs/libstdc++/abi.txt

Under: 

IV. Testing ABI changes

[snip]

One. 
(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 
one with a new compiler and an old library, and the other with an old
compiler and a new library, and look for testsuite regressions)


I did this last night, and unfortunately cannot say that this approach
is currently working with gcc and gcc-3_2-branch C++ binaries. 

Here are my results, which are tenative. I'm re-running these, as I
started this too late last night to really be sure.

I'd apprecaite it if somebody could verify my results.

3.2 libstdc++.so.5 in a 3.3 build directory, make check == 0K
3.3 libstdc++.so.5 in a 3.2 build directory, make check == 15 FAILS

FAIL: 19_diagnostics/stdexceptions.cc execution test
FAIL: 21_strings/append.cc execution test
FAIL: 21_strings/ctor_copy_dtor.cc execution test
FAIL: 21_strings/element_access.cc execution test
FAIL: 21_strings/insert.cc execution test
FAIL: 21_strings/substr.cc execution test
FAIL: 22_locale/ctor_copy_dtor.cc execution test
FAIL: 23_containers/bitset_ctor.cc execution test
FAIL: 23_containers/bitset_members.cc execution test
FAIL: 23_containers/list_modifiers.cc execution test
FAIL: 23_containers/vector_element_access.cc execution test
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess
errors)
FAIL: 27_io/ios_base_storage.cc execution test
FAIL: 27_io/ios_init.cc execution test
FAIL: 27_io/ios_members.cc execution test

		=== libstdc++-v3 Summary ===

# of expected passes		394
# of unexpected failures	15
# of unexpected successes	26


Debugging the first of these... 

/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/g++ -shared-libgcc
-B/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/ -nostdinc++
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
-L/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src
/.libs -B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc-3_2-branch/i686-pc-linux-gnu/include -g
-ffunction-sections -fdata-sections -fmessage-length=0 -DDEBUG_ASSERT
-DLOCALEDIR="/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libst
dc++-v3/po/share/locale" -nostdinc++
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude/i686-pc-linux-gnu
-I/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/inc
lude -I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libsupc++
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/libio
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/include/backward
-I/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc -DDEBUG_ASSERT -lm -o ./stdexceptions.exe

%ldd stdexceptions.exe 
	libstdc++.so.5 =>
/mnt/hd/bld/bld-x86-gcc-3_2-branch/i686-pc-linux-gnu/libstdc++-v3/src/.
libs/libstdc++.so.5 (0x40015000)
	libm.so.6 => /lib/i686/libm.so.6 (0x400d7000)
	libgcc_s.so.1 =>
/mnt/hd/bld/bld-x86-gcc-3_2-branch/gcc/libgcc_s.so.1
(0x400f9000)
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

looks ok

%./stdexceptions.exe 
Abort (core dumped)

(gdb) where
#0  0x42029241 in kill () from /lib/i686/libc.so.6
#1  0x4202902a in raise () from /lib/i686/libc.so.6
#2  0x4202a7d2 in abort () from /lib/i686/libc.so.6
#3  0x400b1407 in __cxxabiv1::__terminate(void (*)()) (
    handler=0x4202a664 <abort>)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x400b1444 in std::terminate() ()
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x400b15c6 in __cxa_throw (obj=0x804b788, tinfo=0x0, dest=0)
    at /mnt/hd/src/src.gcc/gcc/libstdc++-v3/libsupc++/eh_throw.cc:77
#6  0x08049198 in test03() ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:62
#7  0x0804958f in main ()
    at
/mnt/hd/src/src.gcc-3_2-branch/gcc/libstdc++-v3/testsuite/19_diagnostic
s/stdexceptions.cc:110
#8  0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

stepping through it, get to __cxa_throw in eh_thow.cc, line 72:

  // Some sort of unwinding error.  Note that terminate is a handler.
  __cxa_begin_catch (&header->unwindHeader);
  std::terminate ();

Ouch. Isn't this a case of exception regions being screwed?

-benjamin

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

"Goodman, Joe" <joe.goodman@intel.com> writes:

> We provide a C++ ABI test suite you can download from
> http://developer.intel.com/software/products/opensource/.  Please feel free
> to download and run this suite.

Thanks for reminding us.  I did test it some weeks ago and decided to
look again add it - and noticed that I configured it wrong the last
time and was not executing the tests (config.mk disables them by
default on non-ia64 platforms :-( ).

Here're the results on i686-linux-gnu from GCC 3.2 branch as of
2002-08-04:

./bitfield1
Test 1 Failure: bitfield1.cpp:59
./dynamic1
Test 9 Failure: dynamic1.cpp:79
./virtual3
Test 4 Failure: virtual3.cpp:65
./virtual9
Test 9 Failure: virtual9.cpp:92
./vtable1
Test 3 Failure: vtable1.cpp:70
./vtable2
Test 3 Failure: vtable2.cpp:102

And the known failure for new (we have size_t == int on
i686-linux-gnu):

  missing: _Znwm
  missing: _Znam
make: *** [operator1.pass] Error 1

Note that the testsuite aborts after the first error, there might be
more errors - but it's not possible to figure this out right now.

I'll test 3.3 later, I first have to bootstrap it without checking due
to the problems in the x86 backend.  I'll send a report after that.

I don't know whether those failures are critical or not.  Has anybody
looked into these already?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:
> "Goodman, Joe" <joe.goodman@intel.com> writes:
> 
> > We provide a C++ ABI test suite you can download from
> > http://developer.intel.com/software/products/opensource/.  Please feel free
> > to download and run this suite.
> 
> Thanks for reminding us.  I did test it some weeks ago and decided to
> look again add it - and noticed that I configured it wrong the last
> time and was not executing the tests (config.mk disables them by
> default on non-ia64 platforms :-( ).
> 
> Here're the results on i686-linux-gnu from GCC 3.2 branch as of
> 2002-08-04:
> 
> ./bitfield1
> Test 1 Failure: bitfield1.cpp:59

This looks like real problem (if we care about oversized bitfields).
struct A { char a; int b : 224; char c; } x;
g++ now pads field b as if it were long long b : 224, ie.
the fields + its padding has size 32 bytes, offsetof(A, c) == 36
and sizeof(A) == 40.
I've tried g++ 2.96-RH and it gave the expected result, ie.
offsetof(A, c) == 32, sizeof(A) == 36.

> ./dynamic1
> Test 9 Failure: dynamic1.cpp:79

This looks to me like a bug in the testcase:
struct S { int i; };
struct T1 { virtual void f () {} };
struct U3 : public T1, public S { long long l; };
Here offsetof(U3, l) is 8, ie. vptr and i comes before
the long long, yet the testcase requires this to be
sizeof (void *) + sizeof (long long). Why?
On IA-64 where sizeof (void *) == sizeof (long long) this makes no
difference, but on 32-bit arches it does.

> ./virtual3
> Test 4 Failure: virtual3.cpp:65

This again looks like a testcase bug to me:
struct R { int i; };
struct Q { double d; };
struct U2 : virtual public R, public Q { long long l; };
Here offsetof (U2, d) is 4 instead of 8 expected by the testcase,
which is because on IA-32
__alignof__ (Q) != __alignof__ (double).
IMHO the test should use Q type, not double directly.

> ./virtual9
> Test 9 Failure: virtual9.cpp:92

Similarly, this looks like result of
struct Q { long long l; };
__alignof__ (Q) != __alignof__ (long long).

> ./vtable1
> Test 3 Failure: vtable1.cpp:70
> ./vtable2
> Test 3 Failure: vtable2.cpp:102

I don't get these 2. I was using binutils 2.12.90.0.15 if it matters.

> And the known failure for new (we have size_t == int on
> i686-linux-gnu):
> 
>   missing: _Znwm
>   missing: _Znam
> make: *** [operator1.pass] Error 1

Yes, IMHO a bug in the testsuite.

Now I don't claim I must be 100% right in this, so somebody please check
it all again.

And it looks like we very badly need something like this in our testsuite.
IMHO it would be enough to put various kinds of inherited
classes, bitfields etc. into consistency.vlad, and generate output for a few
important platforms...

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 11:25:29AM +0200, Jakub Jelinek wrote:
> > ./vtable1
> > Test 3 Failure: vtable1.cpp:70
> > ./vtable2
> > Test 3 Failure: vtable2.cpp:102
> 
> I don't get these 2. I was using binutils 2.12.90.0.15 if it matters.

Well, I can reproduce these two if I leave -DUSE_FUNCTION_DESCRIPTORS
in config.mk. But, IA-32 doesn't use function descriptors...

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Aug 05, 2002 at 11:25:29AM +0200, Jakub Jelinek wrote:
>> > ./vtable1
>> > Test 3 Failure: vtable1.cpp:70
>> > ./vtable2
>> > Test 3 Failure: vtable2.cpp:102
>> 
>> I don't get these 2. I was using binutils 2.12.90.0.15 if it matters.
>
> Well, I can reproduce these two if I leave -DUSE_FUNCTION_DESCRIPTORS
> in config.mk. But, IA-32 doesn't use function descriptors...

One more problem in front of the computer :-(

Thanks Jakub!
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Nathan Sidwell]

Jakub Jelinek wrote:
> 
> On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:

> > Here're the results on i686-linux-gnu from GCC 3.2 branch as of
> > 2002-08-04:
> >
> > ./bitfield1
> > Test 1 Failure: bitfield1.cpp:59

> > ./dynamic1
> > Test 9 Failure: dynamic1.cpp:79

> > ./virtual3
> > Test 4 Failure: virtual3.cpp:65

> > ./virtual9
> > Test 9 Failure: virtual9.cpp:92

> > ./vtable1
> > Test 3 Failure: vtable1.cpp:70
> > ./vtable2
> > Test 3 Failure: vtable2.cpp:102
I am not seeing any of these failures, with & without
-DUSE_FUNCTION_DESCRIPTORS. Top of cp/Changelog is
2002-08-03  Nathan Sidwell  <nathan@codesourcery.com>

        PR 7470.
        C++ ABI change - vfunc ordering.

> > And the known failure for new (we have size_t == int on
> > i686-linux-gnu):
> >
> >   missing: _Znwm
> >   missing: _Znam
> > make: *** [operator1.pass] Error 1
testcase bug.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Mark Mitchell]

--On Monday, August 05, 2002 11:25:29 AM +0200 Jakub Jelinek 
<jakub@redhat.com> wrote:

> On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:
>> "Goodman, Joe" <joe.goodman@intel.com> writes:
>>
>> > We provide a C++ ABI test suite you can download from
>> > http://developer.intel.com/software/products/opensource/.  Please feel
>> > free to download and run this suite.
>>
>> Thanks for reminding us.  I did test it some weeks ago and decided to
>> look again add it - and noticed that I configured it wrong the last
>> time and was not executing the tests (config.mk disables them by
>> default on non-ia64 platforms :-( ).
>>
>> Here're the results on i686-linux-gnu from GCC 3.2 branch as of
>> 2002-08-04:
>>
>> ./bitfield1
>> Test 1 Failure: bitfield1.cpp:59

Intel's testsuite is (a) somewhat out of date and (b) not fully portable
to all architectures (i.e, makes assumptions that are correct on
Itanium but not necessarily elsewhere).

One of the interesting bits is that the EDG front end does not really
have the idea of "alignment as a field" as opposed to "alignment in
general", which makes it difficult for EDG-based compilers to get
things exactly compatible with GCC.  If Jakub changes bit-field
alignment rules around, that may make this somewhat easier again.

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

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

Andreas Jaeger <aj@suse.de> writes:

> I'll test 3.3 later, I first have to bootstrap it without checking due
> to the problems in the x86 backend.  I'll send a report after that.

GCC 3.3 has the same problems - and removing
-DUSE_FUNCTION_DESCRIPTORS fixed the two vtable bugs that I had.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 01:21:28PM +0200, Andreas Jaeger wrote:
> Andreas Jaeger <aj@suse.de> writes:
> 
> > I'll test 3.3 later, I first have to bootstrap it without checking due
> > to the problems in the x86 backend.  I'll send a report after that.
> 
> GCC 3.3 has the same problems - and removing
> -DUSE_FUNCTION_DESCRIPTORS fixed the two vtable bugs that I had.

BTW: I've fixed the bitfield1.C bug, testing ATM.
But there is another problem - alignment of __m64 fields in records.

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:
> "Goodman, Joe" <joe.goodman@intel.com> writes:
> 
> > We provide a C++ ABI test suite you can download from
> > http://developer.intel.com/software/products/opensource/.  Please feel free
> > to download and run this suite.
> 
> Thanks for reminding us.  I did test it some weeks ago and decided to
> look again add it - and noticed that I configured it wrong the last
> time and was not executing the tests (config.mk disables them by
> default on non-ia64 platforms :-( ).
> 
> Here're the results on i686-linux-gnu from GCC 3.2 branch as of
> 2002-08-04:

On alpha-redhat-linux, the only failing test was:
./bitfield3
Test 4 Failure: bitfield3.cpp:60

This is about:
struct A { char a; char b:1; int :0; char c:1; char d; };
sizeof(A). g++ 3.2 gives 6, the testsuite expects 2*sizeof(int).
That's the same result as given on IA-32 or IA-64, but those
tests are
#if !defined __i386__ && !defined __ia64__
Guess at least __alpha__ is a good candidate for this treatment too.

On ia64-redhat-linux, all tests passed.

Bootstrapping sparc-redhat-linux and sparc64-redhat-linux now and
will run the testsuite there too.

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:
>> "Goodman, Joe" <joe.goodman@intel.com> writes:
>> 
>> > We provide a C++ ABI test suite you can download from
>> > http://developer.intel.com/software/products/opensource/.  Please feel free
>> > to download and run this suite.
>> 
>> Thanks for reminding us.  I did test it some weeks ago and decided to
>> look again add it - and noticed that I configured it wrong the last
>> time and was not executing the tests (config.mk disables them by
>> default on non-ia64 platforms :-( ).
>> 
>> Here're the results on i686-linux-gnu from GCC 3.2 branch as of
>> 2002-08-04:
>
> On alpha-redhat-linux, the only failing test was:
> ./bitfield3
> Test 4 Failure: bitfield3.cpp:60
>
> This is about:
> struct A { char a; char b:1; int :0; char c:1; char d; };
> sizeof(A). g++ 3.2 gives 6, the testsuite expects 2*sizeof(int).
> That's the same result as given on IA-32 or IA-64, but those
> tests are
> #if !defined __i386__ && !defined __ia64__
> Guess at least __alpha__ is a good candidate for this treatment too.

x86-64 has the same problem, everything passes except bitfield3 (this
is with GCC 3.2 plus some extra patches),

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Schwab]

Andreas Jaeger <aj@suse.de> writes:

|> Jakub Jelinek <jakub@redhat.com> writes:
|> 
|> > On Mon, Aug 05, 2002 at 09:00:29AM +0200, Andreas Jaeger wrote:
|> >> "Goodman, Joe" <joe.goodman@intel.com> writes:
|> >> 
|> >> > We provide a C++ ABI test suite you can download from
|> >> > http://developer.intel.com/software/products/opensource/.  Please feel free
|> >> > to download and run this suite.
|> >> 
|> >> Thanks for reminding us.  I did test it some weeks ago and decided to
|> >> look again add it - and noticed that I configured it wrong the last
|> >> time and was not executing the tests (config.mk disables them by
|> >> default on non-ia64 platforms :-( ).
|> >> 
|> >> Here're the results on i686-linux-gnu from GCC 3.2 branch as of
|> >> 2002-08-04:
|> >
|> > On alpha-redhat-linux, the only failing test was:
|> > ./bitfield3
|> > Test 4 Failure: bitfield3.cpp:60
|> >
|> > This is about:
|> > struct A { char a; char b:1; int :0; char c:1; char d; };
|> > sizeof(A). g++ 3.2 gives 6, the testsuite expects 2*sizeof(int).
|> > That's the same result as given on IA-32 or IA-64, but those
|> > tests are
|> > #if !defined __i386__ && !defined __ia64__
|> > Guess at least __alpha__ is a good candidate for this treatment too.
|> 
|> x86-64 has the same problem, everything passes except bitfield3 (this
|> is with GCC 3.2 plus some extra patches),

Same on s390x.  Are there any platforms where it *does* pass?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Daniel Berlin]

> |> > That's the same result as given on IA-32 or IA-64, but those
> |> > tests are
> |> > #if !defined __i386__ && !defined __ia64__
> |> > Guess at least __alpha__ is a good candidate for this treatment too.
> |> 
> |> x86-64 has the same problem, everything passes except bitfield3 (this
> |> is with GCC 3.2 plus some extra patches),
> 
> Same on s390x.  Are there any platforms where it *does* pass?
I could swear I ran these tests on x86 or powerpc (can't remember which) 
when it was first released by Intel, and everything passed. 


> 
> Andreas.
> 
> 

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 09:03:46AM -0400, Daniel Berlin wrote:
> > |> > That's the same result as given on IA-32 or IA-64, but those
> > |> > tests are
> > |> > #if !defined __i386__ && !defined __ia64__
> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
> > |> 
> > |> x86-64 has the same problem, everything passes except bitfield3 (this
> > |> is with GCC 3.2 plus some extra patches),
> > 
> > Same on s390x.  Are there any platforms where it *does* pass?
> I could swear I ran these tests on x86 or powerpc (can't remember which) 
> when it was first released by Intel, and everything passed. 

See Andreas' first mail. Have you actually removed : from RUN= and replaced
: with touch in TOUCH= in config.mk?

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Schwab]

Daniel Berlin <dberlin@dberlin.org> writes:

|> > |> > That's the same result as given on IA-32 or IA-64, but those
|> > |> > tests are
|> > |> > #if !defined __i386__ && !defined __ia64__
|> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
|> > |> 
|> > |> x86-64 has the same problem, everything passes except bitfield3 (this
|> > |> is with GCC 3.2 plus some extra patches),
|> > 
|> > Same on s390x.  Are there any platforms where it *does* pass?
|> I could swear I ran these tests on x86 or powerpc (can't remember which) 
|> when it was first released by Intel, and everything passed. 

On x86 it is explicitly disabled.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Nathan Sidwell]

Daniel Berlin wrote:
> 
> > |> > That's the same result as given on IA-32 or IA-64, but those
> > |> > tests are
> > |> > #if !defined __i386__ && !defined __ia64__
> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
> > |>
> > |> x86-64 has the same problem, everything passes except bitfield3 (this
> > |> is with GCC 3.2 plus some extra patches),
> >
> > Same on s390x.  Are there any platforms where it *does* pass?
> I could swear I ran these tests on x86 or powerpc (can't remember which)
> when it was first released by Intel, and everything passed.
ditto, and the same this morning with the 3.2 branch. I'm confused.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Jaeger]

Nathan Sidwell <nathan@acm.org> writes:

> Daniel Berlin wrote:
>> 
>> > |> > That's the same result as given on IA-32 or IA-64, but those
>> > |> > tests are
>> > |> > #if !defined __i386__ && !defined __ia64__
>> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
>> > |>
>> > |> x86-64 has the same problem, everything passes except bitfield3 (this
>> > |> is with GCC 3.2 plus some extra patches),
>> >
>> > Same on s390x.  Are there any platforms where it *does* pass?
>> I could swear I ran these tests on x86 or powerpc (can't remember which)
>> when it was first released by Intel, and everything passed.
> ditto, and the same this morning with the 3.2 branch. I'm confused.

The problem that I had is that config.mk has:

ifeq ($(shell uname -m),ia64)
        CXX=ecpc
        RUN=
        TOUCH=touch
        LIB=<enter complete library path name>
else
        CXX=g++
        RUN=:
        TOUCH=:
        LIB=<enter complete library path name>
endif

You need to change RUN and TOUCH also (same as ia64 case) - something
I didn't do and therefore everything worked for me since in this case
only compilation is done but no test is executed.

It might be that you made the same error I did, could you double
check, please?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Andreas Schwab]

Daniel Berlin <dberlin@dberlin.org> writes:

|> > |> > That's the same result as given on IA-32 or IA-64, but those
|> > |> > tests are
|> > |> > #if !defined __i386__ && !defined __ia64__
|> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
|> > |> 
|> > |> x86-64 has the same problem, everything passes except bitfield3 (this
|> > |> is with GCC 3.2 plus some extra patches),
|> > 
|> > Same on s390x.  Are there any platforms where it *does* pass?
|> I could swear I ran these tests on x86 or powerpc (can't remember which) 
|> when it was first released by Intel, and everything passed. 

I just tried on ppc and ppc64 and getting the following failures:

ppc:
Test 4 Failure: bitfield3.cpp:60
Test 9 Failure: dynamic1.cpp:79
  missing: _Znwm
  missing: _Znam

ppc64:
Test 4 Failure: bitfield3.cpp:60
Test 1 Failure: fields3.cpp:43

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 03:32:51PM +0200, Andreas Schwab wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> 
> |> > |> > That's the same result as given on IA-32 or IA-64, but those
> |> > |> > tests are
> |> > |> > #if !defined __i386__ && !defined __ia64__
> |> > |> > Guess at least __alpha__ is a good candidate for this treatment too.
> |> > |> 
> |> > |> x86-64 has the same problem, everything passes except bitfield3 (this
> |> > |> is with GCC 3.2 plus some extra patches),
> |> > 
> |> > Same on s390x.  Are there any platforms where it *does* pass?
> |> I could swear I ran these tests on x86 or powerpc (can't remember which) 
> |> when it was first released by Intel, and everything passed. 
> 
> I just tried on ppc and ppc64 and getting the following failures:
> 
> ppc:
> Test 4 Failure: bitfield3.cpp:60
> Test 9 Failure: dynamic1.cpp:79
>   missing: _Znwm
>   missing: _Znam

Just for completeness:
sparc:
Test 4 Failure: bitfield3.cpp:60
Test 9 Failure: dynamic1.cpp:79

	Jakub

Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Janis Johnson]

On Sun, Aug 04, 2002 at 10:20:12PM -0700, Goodman, Joe wrote:
> We provide a C++ ABI test suite you can download from
> http://developer.intel.com/software/products/opensource/ .  Please feel free
> to download and run this suite.
> 
> Joe Goodman
> Intel Corporation
> Software Solutions Group

Joe,

I downloaded Intel's C++ ABI test suite and tried it with GCC 3.2 on
ia64-unknown-linux-gnu and i686-pc-linux-gnu.  It's a great start; here
are some comments about how to make it better.  I'm also sending this
information to Intel via the feedback link at the web page, as
requested in the test suite itself.

- The documentation doesn't really describe just what is being tested.
  From the overview at your web site: "Intel is providing the C++ ABI
  test suite on Linux.  The tests contained in this test suite check a
  C++ compiler for conformance with the C++ ABI."  The C++ ABI has
  generic specifications that apply to all platforms, and specific
  specifications for Itanium.  The test suite apparently is meant for
  use on Itanium, since everything passes there but I got a lot of
  failures on a Pentium III system.

- The config.mk file in the distribution doesn't match comments in the
  README file about what belongs there.  I removed the -D options from
  CXXFLAGS and things didn't work at all, so a comment explaining why
  they're needed would be useful.

- The test suite covers things at a very large granularity; if one check
  in a test fails, then the entire test fails.  That's probably OK for
  getting an answer to "Does this compiler conform to the ABI?" but not
  for "How close is my compiler to conforming to the ABI, and what do I
  need to change to get there?".   I changed abi-test.hpp so that
  ABI_TEST wouldn't exit for a failure and got lots more information
  about failures on i686-linux.  Speaking of which, there's nothing in
  the README or the web site about how to find out what failed, although
  it wasn't difficult to figure out.

- Does Intel intend to add new tests as problems with the ABI are
  uncovered, and for ABI issues with which specific compilers have had
  problems, like the changes that went into GCC between 3.1.1 and 3.2?

- Each file says "All rights reserved" after Intel's copyright notice,
  but it's accessible via a web page labeled "Open Source from Intel",
  which sends mixed signals about what can be done with the tests.  Does
  Intel allow other people to modify and redistribute these tests?  It
  would be useful to have a version that applies to platforms that
  follow the generic specifications of the C++ ABI, and to make that
  available as a plug-in to the GCC test suite as is done now with the
  Mauve test suite for Java.  Would Intel allow that?

The GCC community is discussing ways to test C++ compatibility from
release to release, and Intel's test suite could be a valuable part of
that testing.

Janis Johnson
IBM Linux Technology Center

RE: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility

[Goodman, Joe]

Janis:

Please see my answers to your questions below.  We have recorded your
suggestions and will take them into account in our future ABI testing
efforts.

Joe Goodman
Intel Corporation
Software Solutions Group

The views expressed in this message do not necessarily represent those of
Intel Corporation

-----Original Message-----
From: Janis Johnson [ mailto:janis187@us.ibm.com ]
Sent: Wednesday, August 21, 2002 2:15 PM
To: Goodman, Joe
Cc: bkoz@redhat.com; gcc@gcc.gnu.org
Subject: Re: C++ ABI testing issues, gcc-3.3 <-> gcc-3.2 compatibility


On Sun, Aug 04, 2002 at 10:20:12PM -0700, Goodman, Joe wrote:
> We provide a C++ ABI test suite you can download from
> http://developer.intel.com/software/products/opensource/ .  Please feel
free
> to download and run this suite.
> 
> Joe Goodman
> Intel Corporation
> Software Solutions Group

Joe,

I downloaded Intel's C++ ABI test suite and tried it with GCC 3.2 on
ia64-unknown-linux-gnu and i686-pc-linux-gnu.  It's a great start; here
are some comments about how to make it better.  I'm also sending this
information to Intel via the feedback link at the web page, as
requested in the test suite itself.

- The documentation doesn't really describe just what is being tested.
  From the overview at your web site: "Intel is providing the C++ ABI
  test suite on Linux.  The tests contained in this test suite check a
  C++ compiler for conformance with the C++ ABI."  The C++ ABI has
  generic specifications that apply to all platforms, and specific
  specifications for Itanium.  The test suite apparently is meant for
  use on Itanium, since everything passes there but I got a lot of
  failures on a Pentium III system.

- The config.mk file in the distribution doesn't match comments in the
  README file about what belongs there.  I removed the -D options from
  CXXFLAGS and things didn't work at all, so a comment explaining why
  they're needed would be useful.

- The test suite covers things at a very large granularity; if one check
  in a test fails, then the entire test fails.  That's probably OK for
  getting an answer to "Does this compiler conform to the ABI?" but not
  for "How close is my compiler to conforming to the ABI, and what do I
  need to change to get there?".   I changed abi-test.hpp so that
  ABI_TEST wouldn't exit for a failure and got lots more information
  about failures on i686-linux.  Speaking of which, there's nothing in
  the README or the web site about how to find out what failed, although
  it wasn't difficult to figure out.

- Does Intel intend to add new tests as problems with the ABI are
  uncovered, and for ABI issues with which specific compilers have had
  problems, like the changes that went into GCC between 3.1.1 and 3.2?

>>> Yes, we do plan to add new tests to the suite.

- Each file says "All rights reserved" after Intel's copyright notice,
  but it's accessible via a web page labeled "Open Source from Intel",
  which sends mixed signals about what can be done with the tests.  Does
  Intel allow other people to modify and redistribute these tests?  It
  would be useful to have a version that applies to platforms that
  follow the generic specifications of the C++ ABI, and to make that
  available as a plug-in to the GCC test suite as is done now with the
  Mauve test suite for Java.  Would Intel allow that?

>>> The tests can be modified and redistributed if those tests are licensed
under the Intel 'open source / modified BSD license'.

The GCC community is discussing ways to test C++ compatibility from
release to release, and Intel's test suite could be a valuable part of
that testing.

Janis Johnson
IBM Linux Technology Center