| |||||||||||||
GCC 4.3.0 exposes a kernel bugGCC 4.3.0 exposes a kernel bugPosted Mar 7, 2008 21:37 UTC (Fri) by flewellyn (subscriber, #5047)In reply to: GCC 4.3.0 exposes a kernel bug by zlynx Parent article: GCC 4.3.0 exposes a kernel bug
There's following the standards, and then there's not communicating about a potentially code-breaking change. Because GCC previously was emitting cld instructions before every inlined function call, we can conclude they knew about the problem existing in the wild. They should have given the Linux and BSD developers a heads up about this.
(Log in to post comments)
GCC 4.3.0 exposes a kernel bug Posted Mar 7, 2008 21:55 UTC (Fri) by daney (subscriber, #24551) [Link] GCC changes every day. If you are interested in what every change is, you are free to look at: http://gcc.gnu.org/ml/gcc-cvs/ This particular change to GCC was made many months ago and underwent extensive testing on many different platforms. That this bug existed and was exposed only after 4.3.0 was released is perhaps unfortunate, but you imply that someone knew about the problem and withheld that information. That is not the case.
GCC 4.3.0 exposes a kernel bug Posted Mar 7, 2008 22:27 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] From the gcc point of view, it was simply a matter of observing that the compiler was emitting an unneeded instruction: we don't have to clear that register because it's already cleared; the standard says so, and real implementations follow the standard correctly (or so it was thought). The result was that code sequences that use the x86 string instructions are slightly smaller and faster with gcc 4.3.0.The issue of kernels not following the rules in the case of signal handlers was not noticed until the 4.3.0 release process had already started. If you think that kernel developers should be notified of every change of this kind, just in case it does something, they'd need to subscribe to the svn commit mailing list, and they'd be overwhelmed with messages describing small changes.
GCC 4.3.0 exposes a kernel bug Posted Mar 8, 2008 2:55 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] this is a case where the history of the code is needed to tell what's really going on. did older GCC versions add the instruction because some programmer in the past ran into this bug and fixed it (in which case the changelog for the commit that introduced this would theoretically be found), or was the original programmer of this function in GCC exercising defensive programming by not assuming that other programs leave things in any particular state (which is what was assumed)? how large and how many clock cycles does this instruction use?
GCC 4.3.0 exposes a kernel bug Posted Mar 8, 2008 19:21 UTC (Sat) by ibukanov (subscriber, #3942) [Link] History may not be relevant here. It could be that in the past GCC was simply not able to track the state of the control bit when generation the code. As such the compiler had to insert the explicit instructions to reset the bit even if it was known that they were not necessary from ABI point of view.
GCC 4.3.0 exposes a kernel bug Posted Mar 9, 2008 3:37 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link] the history is very relevant. you are listing a third option (very similar to the second one I listed above) knowing which of these is correct (or if there is a fourth that is correct) is significant in evaluating what needs to change.
Was it worth the trouble? Posted Mar 8, 2008 22:46 UTC (Sat) by eru (subscriber, #2753) [Link] The result was that code sequences that use the x86 string instructions are slightly smaller and faster with gcc 4.3.0.The eliminated instruction is one byte long, executes very quickly, and string instructions are not very common in most real code anyway. When they occur, they are heavyweight operations, because the sources and count have to be set up into particular registers, and the string instruction itself usually takes much more time than simple instructions. Whether or not the direction flag instruction appears might then change the time of the string operation by perhaps 1% or less. So except for contrived programs that consist almost entirely of these string operations, I suspect it is impossible to measure any execution time reduction in actual programs that could be attributed to this compiler change. Of course removing a redundant instruction is aesthetically the right thing to do, but in this case I think it does not have practical benefits.
Was it worth the trouble? Posted Mar 9, 2008 20:07 UTC (Sun) by vonbrand (subscriber, #4458) [Link]
Was it worth the trouble? Posted Mar 19, 2008 9:38 UTC (Wed) by pharm (guest, #22305) [Link] <i>The eliminated instruction is one byte long, executes very quickly, and string instructions are not very common in most real code anyway. When they occur, they are heavyweight operations, because the sources and count have to be set up into particular registers, and the string instruction itself usually takes much more time than simple instructions. Whether or not the direction flag instruction appears might then change the time of the string operation by perhaps 1% or less. So except for contrived programs that consist almost entirely of these string operations, I suspect it is impossible to measure any execution time reduction in actual programs that could be attributed to this compiler change.</i> Unfortunately, you're wrong. CLD can have a latency of 50+ cycles on some x86 implementations: that's not an insignificant amount. Plus we're not just talking about "string operations", we're talking about functions like memset() & memcpy() too, which often use them. See: http://gcc.gnu.org/ml/gcc/2008-03/msg00360.html for some benchmarks and http://gcc.gnu.org/ml/gcc/2008-03/msg00404.html for a link to a document which gives a latency of 52 cycles for CLD.
|
|||||||||||||