--- Comment #7 from paolo at gcc dot gnu dot org 2009-12-11 22:05 ---
Subject: Bug 42352
Author: paolo
Date: Fri Dec 11 22:04:56 2009
New Revision: 155180
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155180
Log:
2009-12-11 Paolo Carlini
PR libstdc++/42352
*
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-11 22:10
---
list::sort (both overloads) should be fine now, if you notice something
strange, please let me know...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from rwgk at yahoo dot com 2009-12-12 05:49 ---
Thanks very much for the quick fix!
It didn't clear up all errors of this type, though, when compiling our code (I
verified that the original problem is fixed). Based on your comments I decided
to remove the -std=c++x0 for th
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-12 09:10
---
What do you mean by "of this type"? As I tried already to explain, until the
ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
list::splice. If, however, you are seeing problems with calls to
--- Comment #11 from paolo dot carlini at oracle dot com 2009-12-12 09:17
---
Just to clarify a bit more: if, on the other hand, you are seeing problems
*outside* the library, because you used to rely in your code on rvalue
references binding to lvalues, there is absolutely nothing we a
--- Comment #12 from rwgk at yahoo dot com 2009-12-14 06:05 ---
(In reply to comment #10)
> What do you mean by "of this type"? As I tried already to explain, until the
> ISO C++ Committee resolves DR 1133 we cannot touch list::merge and
> list::splice.
Sorry, I wasn't looking carefull
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-14 08:39
---
Yes, you understood correctly, that is our policy and nothing changes if you
overstate the issue by using the "broken" catch-all. To repeat, our general
policy is that any issue corresponding to an ISO DR is n
--- Comment #14 from rwgk at yahoo dot com 2009-12-19 15:09 ---
(In reply to comment #13)
> That said, this specific issue has been moved yesterday to [Tentatively Ready]
> and it's safe enough to simply re-add for now the C++03 set of overloads (we
> don't implement yet the C++0x alloca
--- Comment #15 from paolo dot carlini at oracle dot com 2009-12-19 20:29
---
Good ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
