> Could that be related to the fact that I now keep getting linker
> errors about std::range_error::~range_error() being undefined?
> The .o file is looking for _ZNSt11range_errorD2Ev but libstdc++ has
> D0Ev and D1Ev.
Indeed. Fixed thusly.
tested x86/linux
-benjamin
2011-03-16 Benjamin Kosn
On Mon, 14 Mar 2011, Benjamin Kosnik wrote:
I hacked up scripts/check_compile and ran the libstdc++ testsuite to
generate 4k+ .s files, and then analyzed the resulting assembly files
for vague linkage.
Here are the clear wins that are ABI-compatible, or in C++0x code. There
are other issues, li
Like so.
-benjamin2011-03-15 Benjamin Kosnik
* include/std/thread: Revert.
* src/thread.cc: Same.
* config/abi/pre/gnu.ver: Same.
Index: src/thread.cc
===
--- src/thread.cc (revision 171019)
+++ src/thread.cc (working copy)
@
> thread::_Impl_base was one I'd been prototyping some changes to. If we
> need to rework it in order for thread::id to be a trivially-copyable
> (and less-than-comparable) type then we might need additional virtuals
> in Impl_base, but as all I have are untested ideas for now it probably
> should
On 15 March 2011 19:19, Benjamin Kosnik wrote:
>
>> Does exporting some of these symbols and vtables from the library mean
>> we're less able to change them? I'm not confident all ofthe C++0x
>> bits are entirely stable yet.
>
> Yes, it does. What are the new exports that concern you?
thread::_Im
> Does exporting some of these symbols and vtables from the library mean
> we're less able to change them? I'm not confident all ofthe C++0x
> bits are entirely stable yet.
Yes, it does. What are the new exports that concern you?
There are some things I purposely did not include. For instance
On 14 March 2011 17:29, Benjamin Kosnik wrote:
>
> I hacked up scripts/check_compile and ran the libstdc++ testsuite to
> generate 4k+ .s files, and then analyzed the resulting assembly files
> for vague linkage.
>
> Here are the clear wins that are ABI-compatible, or in C++0x code. There
> are oth
> It broke build, hopefully for trivial reasons. It seems like
> your bugzilla options are set to not receive email, so I'll have
> to bug you like this, and ask that you please have a look at
> PR48130.
No problem. Sorry about the breakage. Indeed, it was trivial.
> > tested x86_64/linux
t
On Mon, 14 Mar 2011, Benjamin Kosnik wrote:
> This is versioned for 4.6.0, but I'll wait a day or two to see how it
> goes before I plead with the RMs.
It broke build, hopefully for trivial reasons. It seems like
your bugzilla options are set to not receive email, so I'll have
to bug you like thi
