--- Comment #6 from paolo at gcc dot gnu dot org 2010-06-09 09:16 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 09:15:51 2010
New Revision: 160456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160456
Log:
2010-06-09 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-09 14:02 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 14:02:03 2010
New Revision: 160476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160476
Log:
2010-06-09 Paolo Carlini paolo.carl...@oracle.com
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:13
---
I gave this more thought, and to be honest, focusing on 64-bit targets - I
think that for 32-bit targets what we have is already good enough - I have no
idea how to substantively improve the code, given that
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 00:26
---
As far as we can see can't be substantively improved. See also the thread
starting at: http://gcc.gnu.org/ml/libstdc++/2010-06/msg00073.html
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #3 from dgohman at gmail dot com 2010-06-08 14:54 ---
Callers of compare are already exposed to __builtin_memcmp result values (with
default traits) which vary depending on the target and compiler flags.
And since _S_compare is only used as a tie-breaker after the memcmp,
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-08 15:09
---
I'm not convinced. The code at issue is used when memcmp returns zero, thus one
string is a prefix of the other, a well defined situation. For *eons* we have
been returning a number which is much larger (in
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-08 15:59
---
Let's do this change first in ext/vstring and let's see how people react. In
that case we also have the advantage that nothing is exported from the *.so,
thus old code linking to the new lib will not risk
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-07 14:52
---
I think Jon is right on both accounts: the request is reasonable, but, even
before that last changes, thus since the very beginning of v3:
if (!__r)
__r = __size - __osize;
thus, I think
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-04 16:52 ---
Seems like a reasonable suggestion for improvement. I don't know if anyone
relies on the current behaviour, so it might not get changed.
--
redi at gcc dot gnu dot org changed:
What|Removed
