[PATCH] libstdc++/8761 and libstdc++/7076

[Benjamin Kosnik]

>In this particular patch, I only cached the actual ctype facet since
>I haven't put together the patch for using the _M_literals field yet.
>Once that happens I won't actually need the ctype reference for this
>purpose.
>
>I'll take a look at the _M_fcvt stuff as well.
>
>If the format cache is a reasonable way to go in general, we could
>cache the facets directly in a map or hash indexed by typeid name.

Just be careful: if you plan to extend the idea of caching locale data
in the future, then the name format cache is not really accurate, is it?

Also, look at __num_base. If you are just storing const char* string
literals, or any other data (enums, ints, strings) that don't change
based on the template parameter, they don't have to be duplicated in
templatized class structures: just use a common base class.


> > This compiles, I do get an extra link fail in
> > 22_locale/num_put_members_char.cc, but it's probably something .... I
> > will look at it in a bit (seems wierd, it's defined in src/locale.cc)
> > and 27_io/ios_manip_basefield.cc also has an execution fail. Also
> > 27_io/ostream_inserter_arith. These may both be export-list related, or
> > not. Hmm.
>
>I can also keep looking at these issues, but it gets into territory
>I'm less sure of.

Don't worry about the link fails, I'll take care of it.

The non-link, execute fails absolutely have to be fixed before this can go in.

>When regression testing, the strategy is to run the test on the
>unmodified library and then run again afterwards and compare, correct?

Yep.

> > The c_locale.h duplication between gnu and generic is unfortunate but
> > necessary for the moment. 
>
>When does the gnu c_locale.h get used vs. the generic?  What code
>should go into c_locale.cc, in either dir?

The files in config/locale/* (namely c_locale) are configure-dependant,
whereas bits/locale_facets.h, bits/locale_facets.tcc are included by all
hosts and targets, regardless of configure options.

There are three ways to configure locales: generic ("C" only), gnu, and
iee-2001.103 (SUS, POSIX).

> > How do I go about verifying the performance issues again?
>
>I used the test case in libstdc++/8761 to work on this.  Afterwards, I
>found that libstdc++/7076 seems to be largely the same issue, so I've
>validated that test case as well.

OK.

>BTW, I've been working along the 3.3 branch.  I thought this was okay,
>since we're dealing with a regression, but if you think I should
>switch to mainline, I will do that.  Although I'd really like to see
>this get into 3.3 if possible.

There is little (none?) divergence between gcc-3_3 and gcc CVS at the
moment, so your patch applies cleanly to either one. Usually I work from
gcc sources and port to the various branches.

>I can actually ditch _S_pword_ix, as long as it is OK to reserve the
>pword(0) slot of ios_base as I've done in this patch.  Do you want a
>comment in ios_base indicating this?  If someone else tries to use
>slot 0, they may be in for some pain :-)

Definitely comment it, and then ditch _S_pword_ix. 

-benjamin