current gcc-mainline/i386-unknown-freebsd7.2 failures, initial thoughts

[Loren James Rittle <rittle at latour dot labs dot mot dot com>]

First of all: Hello World!

So, it is time to give libstdc++-v3/freebsd some love.  Here are the
known failures on 4.4.2/i386-unknown-freebsd7.2 without -pthread:

Assertion failed: (is.fail()), function test12_aux, file [...]libstdc++-v3/\
testsuite/27_io/basic_istream/extractors_arithmetic/char/12.cc, line 56.
FAIL: 27_io/basic_istream/extractors_arithmetic/char/12.cc execution test

FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/12.cc execution test

Both appear to fail because the istream is not marked as failing when
it parses an overflown long double.  On the plus side, the test case
is not crashing.  Since this smells like a long-known [fp/i386] issue,
I will not look further today.

[...]/libstdc++-v3/testsuite/util/thread/all.h:45:35: error: invalid \
application of 'sizeof' to incomplete type \
'__gnu_test::compare_type_to_native_type() \
[with _Tp = std::thread]::native_type'
[...additional compilation errors...]
FAIL: 30_threads/thread/native_handle/typesizes.cc (test for excess errors)

The problem here is that FreeBSD does not expose the implementation of
pthread_t to user code (nor could it given the number of unique
implementations that may be applied at run-time).  Here is what you
get from the system headers:

struct pthread;
typedef struct pthread *pthread_t;

Therefore, I think I have to mark this test as xfail for *-*-freebsd*.
It will never pass as written.  In any event, I admit that I don't
really understand the purpose of this test.  Why does std::thread need
to match size/alignment with the underlying native thread library
implementation?  (for they are never, ever interchangeable, are they?)

Extra failures seen on mainline:

terminate called after throwing an instance of '__gnu_test::counter_error'
  what():  std::exception
operator new is called 
FAIL: ext/new_allocator/deallocate_global.cc execution test

terminate called after throwing an instance of '__gnu_test::counter_error'
  what():  std::exception
operator new is called 
operator new is called 
FAIL: ext/throw_allocator/deallocate_global.cc execution test

No ideas on these yet (other than a pure guess that de/constructors
are running "out of order").

Extra failures seen with -pthread:

terminate called after throwing an instance of '__gnu_cxx::__concurrence_unlock_
error'
  what():  __gnu_cxx::__concurrence_unlock_error
FAIL: ext/bitmap_allocator/variadic_construct.cc execution test

No ideas yet.

Regards,
Loren