This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH: libstdc++/include/profile bug fixes and cleanup
- From: Silvius Rus <rus at google dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org, Benjamin Kosnik <bkoz at redhat dot com>
- Date: Thu, 7 Jan 2010 16:15:21 -0800
- Subject: Re: PATCH: libstdc++/include/profile bug fixes and cleanup
- References: <e90dbffc1001071505n65f41ce3v8ed28f9214f673a@mail.gmail.com> <4B46722C.3040101@oracle.com>
On Thu, Jan 7, 2010 at 3:45 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> just a few words, Benjamin knows your work much better than me...
Sure. I'll wait for Benjamin's review.
>> 4. Cleanup: Drop support for hash_map and hash_set.
>> Requested by library maintainer Paolo Carlini.
>> http://gcc.gnu.org/ml/libstdc++/2010-01/msg00026.html
>>
> Excellent. I totally support this, for all the reasons already explained.
>> Tested:
>> x86_64/linux make check-profile
>> There were 14 FAILs. ?I will make them pass or ask for specific help
>> before submitting.
>>
> Too bad. Last time I checked, a few days ago, things were ok, besides
> the usual synopsis.cc, which are expected, and little else, I think...
Well, the on/off switch was broken, so none of the exec tests were
actually doing anything. And I added new instrumentation code
which probably requires several flavors of each method to be
brought in. The errors don't seem too hard to fix though FLW.
>>
>> Questions to maintainers:
>>
>> 1. Currently, multithreaded execution of the profile mode requires
>> TLS. ?Is this a reasonable way to test TLS support?
>> #if (defined _GLIBCXX_PROFILE_THREADS) && !(defined HAVE_TLS)
>> #error profile mode requires either -DHAVE_TLS or -D_GLIBCXX_PROFILE_NO_THREADS
>>
> In general, much better _GLIBCXX_HAVE_TLS, which is uglified, you can
> find it used in a couple other places in the library, mutex.cc,
> eh_globals.cc.
Great, thank you for letting me know. That's why configure wasn't
setting it the way I expected. I was just looking for the wrong name.
>> 2. I am testing for execinfo.h with #ifdef HAVE_EXECINFO_H.
>> What is the right way to make sure this gets set in a config file?
>>
> Again, in the library, in general, always prefer uglified things, thus
> _GLIBCXX_HAVE_EXECINFO_H. Then I would guess that just adding execinfo.h
> to the list of headers searched at line # 168 of configure.ac should be
> enough (I suppose you know already how to regenerate the configury by
> invoking autoreconf, using autoconf-2.64 and automake-1.11, those exact
> versions of the tools, it's important)
>
> Paolo.
>
I haven't used autoconf for years, but I did notice the list of
headers in configure.ac.
I'll try it out and get back only if I can't make it work.
Thank you,
Silvius