Dan Price points out that this could be a case where some "volatility" is necessary. I made the loop counter "i" volatile, and the problem went away. Looking at the disassembly and comparing for the two cases (siglongjmp)
(volatile) benchmark+0x1b: 8d 45 fc leal -0x4(%ebp),%eax <--- Get ptr to "i" benchmark+0x1e: 8b 10 movl (%eax),%edx benchmark+0x20: 89 d1 movl %edx,%ecx <--- Stuff current "i" into ecx benchmark+0x22: 42 incl %edx <--- i++ into edx benchmark+0x23: 89 10 movl %edx,(%eax) <--- Store back to memory benchmark+0x25: 83 c4 10 addl $0x10,%esp benchmark+0x28: 3b 0d 38 42 06 08 cmpl 0x8064238,%ecx <--- Test pre-increment i benchmark+0x2e: 7d 0d jge +0xf <benchmark+0x3d> <---- break out if needed (original) benchmark+0x17: 83 3d 38 42 06 08 00 cmpl $0x0,0x8064238 benchmark+0x1e: 7e 0d jle +0xf <benchmark+0x2d> Before the volatile, we're compating lm_optB to zero. Looks like "i" isn't in the picture. The gcc optmizer thinks that siglongjmp() is a one-way ticket out of the function, so it doesn't bother incrementing "i" before executing the loop block. It only tests it against "0" the first time. In the case of longjmp.c siglongjmp.c, these diffs will fix things: [EMAIL PROTECTED] sccs diffs longjmp.c siglongjmp.c ------- longjmp.c ------- 29c29 < int i = 0; --- > volatile int i = 0; ------- siglongjmp.c ------- 38c38 < int i = 0; --- > volatile int i = 0; We'll look into this further (including what's going on connection) This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
