> From: Shilimkar, Santosh > Sent: Monday, April 20, 2009 11:39 PM > Thanks Richard for root casing the issue. > > Yes I also did observed this. Second time when framework calls > "omap2_gp_timer_set_mode" set the periodic mode, R0 contains 0 > (CLOCK_EVT_MODE_UNUSED) instead of 2(CLOCK_EVT_MODE_PERIODIC). > > The assembly generated looks shocking because it prepares the second function > arguments in register R1 as expected and then 'pop' destroys it. A "push" > before a function call is reasonable but this not quite understandable. > > Can this be taken up with Codesorcery team to check what is triggering > compiler to generate such an assembly ? The compiler version is old enough I wouldn't anticipate they would do a fix unless someone was using this for production. Typically they release some for pay fix ups around a base. This may or may not be fixed in one of those. If anyone is using it they should speak up. The compiler probably noticed it could optimize away the function return point (can ret back to caller from called function instead of present one after call. It then messed up). Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
