I'm looking for help for the profile-mode version (I'm going to take care of the debug-mode one)
Subject: Re: profile-mode version of forward_list missing On Sun, Mar 28, 2010 at 3:36 AM, paolo dot carlini at oracle dot com <gcc-bugzilla@gcc.gnu.org> wrote: > > > -- > > paolo dot carlini at oracle dot com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > Last reconfirmed|0000-00-00 00:00:00 |2010-03-28 10:36:29 > date| | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43554 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. Hello Paolo, Could you please assign it to me. (Also feel free to assign any other unclaimed profile mode bugs to me, current or future.) Thank you, Silvius
It's not clear from the description what the problem is here. The profile mode doesn't instrument either forward_list or slist at this point, so all inclusions of <forward_list> should fall back to normal mode. Could you please clarify the problem?
Silvius, this is not a bug proper, instead an *enhancement* request: it seems quite obvious to me, if only for consistency, that we want to provide debug-mode and profile-mode versions of forward_list too, like all the other containers, no?!?
Oh, OK. I misunderstood. Then let's keep it open to track the addition of new modules including forward_list.
Yes ;) I'm going to work asap on debug-mode, certainly we want it too for 4.6.0, but it's a bit tricky because of the special way many operations are specified in terms of the *preceding* element: debug-mode is missing a bit of infrastructure for that.
The debug-mode bits are now in. It would be nice to have the profile-mode bits too for 4.6.0...
Hello Paolo, Thank you for the notification. It's *much* easier to use debug mode as a template than to start from scratch. What is the time frame for 4.6.0? For reference, what needs to be done at this point is a couple of new diagnostics 1. "forward_list to vector": if the only operations are "insert_after last element" and iteration, and if the size is always about the same. 2. "forward_list to deque": this needs a cost model. Paolo, would it make sense to open tickets for other diagnostics as well, even if it would take me a while to close them? Maybe some student out there will pick them if they're well defined. Thank you, Silvius On Wed, Sep 29, 2010 at 5:01 AM, paolo.carlini at oracle dot com < gcc-bugzilla@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43554 > > --- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> > 2010-09-29 12:01:16 UTC --- > The debug-mode bits are now in. It would be nice to have the profile-mode > bits > too for 4.6.0... > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. >
(In reply to comment #8) > What is the time frame for 4.6.0? We are still in Stage 1, but I don't have many details at the moment, I would suggest simply following the various announcements on the gcc mailing list. > For reference, what needs to be done at this point is a couple of new > diagnostics > 1. "forward_list to vector": if the only operations are "insert_after last > element" and iteration, and if the size is always about the same. > 2. "forward_list to deque": this needs a cost model. Ok... > Paolo, would it make sense to open tickets for other diagnostics as well, > even if it would take me a while to close them? Maybe some student out > there will pick them if they're well defined. If you ask me, normally we don't open many PRs for pure enhancement issues, the situation can quickly grow without control. After all, Bugzilla is for *bugs*. Thus I would recommend summarizing those issues to a minimal number of PRs, better if each has a student already "assigned", somehow.
Silvius -- due to the recent changes to the normal-mode forward_list to enable the debug-mode version (essentially the use of a nested namespace), now simply including <forward_list> as part of a profile-mode build breaks everything. Just run make check-profile to see what I mean. I can add a dummy profile-mode forward_list, not profiling anything, just let me know if you actually mean to implement something beyond that. Thanks.
I'm not able to get in contact with Silvius. Thus I'm adding a dummy profile-mode forward_list myself, and hoping for substantive work from the contributors of profile-mode in the future (by the way, the situation with <bitset> seems quite similar).
Author: paolo Date: Sun Oct 17 14:49:11 2010 New Revision: 165587 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165587 Log: 2010-10-17 Paolo Carlini <paolo.carlini@oracle.com> PR libstdc++/43554 * include/profile/forward_list: New file. * include/std/forward_list: Include <profile/forward_list>. * include/Makefile.am: Add. * testsuite/23_containers/forward_list/capacity/1.cc: Adjust. * include/Makefile.in: Regenerate. Added: trunk/libstdc++-v3/include/profile/forward_list Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/std/forward_list trunk/libstdc++-v3/testsuite/23_containers/forward_list/capacity/1.cc
I'm closing this.