This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

mt_alloc switch diagnosis


There are three general kinds of issues.

1) demangle.cc implicit instantiations vs. explicit instantiations. This
was the darwin bootstrap failure, as __mt_alloc<int> was implicitly
instantiated in demangle.cc, and explicitly instantiated later on.  I've
got this fixed, now.

2) static data. On systems without weak, static data is not emitted by
g++, in the hopes that not emitting it will only provoke the linker by
giving missing symbols, which can than be forcibly instantiated, whereas
emitting it would result in duplicate symbols.

The problem is that each __mt_alloc instance has a lot of static data:
in order for libstdc++ to work on systems with weak linkage and without
weak linkage, we'd have to explicitly instantiate the static data for
non-weak systems. This is already done for a lot of the testcases that
play around with non-required std::basic_string types. 

Duplicating this work for something like std::allocator is not something
I am eager to do. The old underlying allocator, __pool_alloc<0, 1> was
used for all instances of std::allocator, so only had to be instantiated
once.

Instead:

- maybe use a base allocator that doesn't have static data
(new_allocator), by explicitly using this as the allocator type in the
tests. (And the demangler?)

- maybe put the static data member in a non-templatized __mt_alloc base
class, and just have it defined in libstdc++ once. I think this is the way to go.


3) thread support. David E fixedup src/allocator.cc. However, other
problems remain.  It assumes _GTHREAD_MUTEX_INITIALIZER: this may not
always be the case. For instance, cygwin. If you look at pool_alloc
you'll see the song-and-dance required.

I don't know the best solution for this problem. I'm not a fan of
bits/stl_threads.h, but apparently it has some uses. I'd rather go with
bits/concurrence.h but I don't have the time to finish it at the moment.

So..... anyway. There is one other issue, which is completely minor.

4) Comment style in mt_alloc.h is a bit odd. Doxygen comments are usually:

/**

*/

and regular comments are usually

//

A lot of these comments are neither. Not a big deal.

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]