Hi
2024. március 13., szerda 12:43 keltezéssel, Jonathan Wakely
<jwak...@redhat.com> írta:
> On Mon, 11 Mar 2024 at 23:36, Barnabás Pőcze <po...@protonmail.com> wrote:
> >
> > Previously, calling erase(key) on both std::map and std::set
> > would execute that same code that std::multi{map,set} would.
> > However, doing that is unnecessary because std::{map,set}
> > guarantee that all elements are unique.
> >
> > It is reasonable to expect that erase(key) is equivalent
> > or better than:
> >
> > auto it = m.find(key);
> > if (it != m.end())
> > m.erase(it);
> >
> > However, this was not the case. Fix that by adding a new
> > function _Rb_tree<>::_M_erase_unique() that is essentially
> > equivalent to the above snippet, and use this from both
> > std::map and std::set.
>
> Hi, this change looks reasonable, thanks for the patch. Please note
> that GCC is currently in "stage 3" of its dev process so this change
> would have to wait until after GCC 14 branches from trunk, due in a
> few weeks.
OK; I didn't know that, thanks for telling me.
>
> I assume you ran the testsuite with no regressions. [...]
I hope so. I ran `make check-target-libstdc++-v3`, and it did not note any
unexpected failures as far as I can see:
Native configuration is x86_64-pc-linux-gnu
=== libstdc++ tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /gcc/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /gcc/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ...
Running /gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ...
Running
/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp ...
Running /gcc/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp ...
=== libstdc++ Summary ===
# of expected passes 18646
# of expected failures 126
# of unsupported tests 672
> [...] Do you have benchmarks to show this making a difference?
As for benchmarks, I do not have any. But even if the performance does not
improve appreciably, the size of the generated code will definitely be smaller.
And in the end, the excessive code was the reason I opened the mentioned
issue[0]
in the first place, which should be eliminated hopefully.
> [...]
Regards,
Barnabás Pőcze
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
