| |||||||||||||
GCC 4.3.0 exposes a kernel bugGCC 4.3.0 exposes a kernel bugPosted Mar 8, 2008 2:55 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: GCC 4.3.0 exposes a kernel bug by JoeBuck Parent article: GCC 4.3.0 exposes a kernel bug
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?
(Log in to post comments)
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.
|
|||||||||||||