Roman wrote:
OK, thanks for the patch, it fixed compilation errors. Just to let you know, there is a bug in some of the benchmarks - longjmp.c and siglongjmp.cint benchmark(void *tsd, result_t *res) { int i = 0; jmp_buf env; (void) setjmp(env); i++; if (i < lm_optB) longjmp(env, 0); res->re_count = i; return (0); } On NetBSD sparc64, compiled with gcc and -O2 optimisations, the benchmark goes into infinite loop, because of the way automatic variables are handled after calling longjmp(), i.e. their value is indeterminate, which is affected by compiler optimisations. In this case, I observed that variable i was incremented to some large number, but then reset to 0. To fix this, you'd need to declare i as 'volatile' Richard Stevens explains this very well in his "Advanced Programming in the Unix Environment" on page 178
Thanks... I need to patch this; we've hit this before. I wish gcc would grok either #pragma unknown_control_flow(setjmp) or extern void longjmp(jmp_buf, int) __NORETURN; - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
