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

[Jerry Quinn]

Benjamin Kosnik writes:
 > Sorry I'm so behind on patch review at the moment. Regardless of
 > long-term issues of format cache versus locale info cache, this is some
 > feedback on your patch as is.
 > 
 > There was an attempt to cache facet values directly in the io heirarchy
 > in the past. See _M_fcvt, etc. These, and the _Format_cache bits were
 > taken out at the same time due to corectness issues.
 > 
 > Now that locales are on more solid ground, it's time to look at figuring
 > out how to do a general cache strategy. 

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.


 > On Fri, 10 Jan 2003 01:50:20 -0500
 > Jerry Quinn <jlquinn@optonline.net> wrote:
 > 
 > >I believe I've put the specializations in the right place, but please verify.
 > 
 > You did, there were some very minor bits. There is some confusion in the
 > curent code about declaration of other specializations vs. definitions
 > of generics (ie more of libstdc++/9269) so I can see why you'd be a bit
 > uncertain. I fixed this up in this version of your combined patches,
 > plus moved some things around a bit, so maybe it's easier to see where
 > to put the specialization declarations, and generic definitions.
 > 
 > 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.

 > Did you run 'make check' and 'make check-abi?'. Hmm.

I did run into some issues with make check and should have said so.
Sorry.  Where is make check-abi documented?  I missed seeing a
reference to it.

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

 > 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?

 > 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.

 > 
 > best,
 > benjamin


Thanks for looking at this.

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.

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 :-)

Jerry Quinn