| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 11, 2010 7:20 UTC (Thu) by kunitz (subscriber, #3965)In reply to: Glibc change exposing bugs by bojan Parent article: Glibc change exposing bugs
If that's the case the optimization shouldn't be enabled on Core i5. I guess it's more difficult to test for the CPU then for SSE 4.x presence.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 11, 2010 18:23 UTC (Thu) by oak (subscriber, #2786) [Link]
> If that's the case the optimization shouldn't be enabled on Core i5
What would be the point of slowing down memcpy for all CPUs (by adding an extra check for cached CPU type variable value)? As long as the change doesn't slow down things for other CPUs, and considerably speeds it up on some, it sounds fine...
Glibc change exposing bugs Posted Nov 12, 2010 0:37 UTC (Fri) by jamesh (guest, #1159) [Link]
That would mean that a developer using a Core i5 will not be able to reproduce some bugs seen by users on Core 2 and Atom chips. Is that actually desirable?
Glibc change exposing bugs Posted Nov 12, 2010 10:51 UTC (Fri) by marcH (subscriber, #57642) [Link]
No, but something like this happens every time developers rely on undefined behaviour, so we just have to live with it.
|
|||||||||||||