Re: STL bug with 4.0?
Re: STL bug with 4.0?
- Subject: Re: STL bug with 4.0?
- From: Howard Hinnant <email@hidden>
- Date: Wed, 23 Nov 2005 14:46:36 -0500
Glad to hear you got it figured out. I should've mentioned the <=
possibility too (making a note to myself to remember that one next
time this question pops up). The lack of check is a speed
optimization on a tight inner loop. It really makes a difference.
But perhaps a future debug build could be more forgiving in the
future and make some noise if this situation occurs ...
-Howard
On Nov 22, 2005, at 12:31 PM, Scott Andrew wrote:
So this seemed to be a difference in STL implemenations. When we
called sort our sort predicate did a check, it did a <= check. In
GCC 4.0 there is no check for hitting the middle or end of the list
when doing a sort the <= check in cases returned true enough to
where it finally just ran of the end of the vector.
However we changed to just < and all is well
Scott Andrew
On Nov 21, 2005, at 5:36 AM, Howard Hinnant wrote:
On Nov 20, 2005, at 11:11 PM, Scott Andrew wrote:
__unguarded_partition bug? I have some code that is call
std::sort of 50K of items. It seems that somewhere down the line
that __unguarded_partition is loosing a pointer and trying to
read beyond where it should. has onyone see this issue. Are there
patches to the STL files anywhere?
I have reviewed __unguarded_partition, and its role within sort.
I have searched both this list, and the gcc lists for report of a
problem with sort and/or __unguarded_partition. I can not find
any evidence of a bug. Would it be possible for you to send us a
demo of this problem?
The only way I can currently see for __unguarded_partition to read
beyond where it should is if the comparison operator/data set does
not form a strict weak ordering. This could happen for example,
if using the built-in less than operator on floating point types.
If a nan creeps into the data, less-than no longer forms a strict
weak ordering. For example if x is a nan, and y is 3, and z is 6
then:
!(x < y) && !(y < x) -> true, x (nan) and y (3) are equivalent
!(x < z) && !(z < x) -> true, x (nan) and y (6) are equivalent
Therefore, if this is a strict weak ordering, y (3) and z (6) are
also equivalent (which is obviously false).
The problem could be either in a faulty comparison operator, or in
a corrupted range containing data over which the comparison
operator isn't valid.
Switching sort implementations may not fix this behavior, or worse
yet, it might make the behavior harder to detect.
Compiling with the compiler flag -D_GLIBCXX_DEBUG (STL debug
mode), may help expose the root cause of this problem.
-Howard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden