On Fri 27 Jan 2006 at 05:22PM, Roman wrote:
> I've given up, this benchmark needs more thought and testing. Some
> tests just get stuck in infinite loops
>
> Running: mallocT2_1k
>
> 10 hours later, it's still running... and that is on 440MHz Sparc
> machine, running Solaris 10.
>
> Rest
I've given up, this benchmark needs more thought and testing. Some tests just
get stuck in infinite loops
Running: mallocT2_1k
10 hours later, it's still running... and that is on 440MHz Sparc machine,
running Solaris 10.
Restarted the benchmark again, and that test completed in 0.03 s
On Tue 24 Jan 2006 at 09:33AM, Bart Smaalders wrote:
> >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
Frank van der Linden wrote:
It groks the noreturn void exit __P((int)) attribute, e.g.
err.
Pasto. I meant 'the noreturn attribute'.
___
perf-discuss mailing list
perf-discuss@opensolaris.org
Bart Smaalders wrote:
I wish gcc would grok either
#pragma unknown_control_flow(setjmp)
or
extern void longjmp(jmp_buf, int) __NORETURN;
It groks the noreturn void exit __P((int)) attribute, e.g.
void exit(int) __attribute__((__noreturn__));
Looks like uts/common/sys/ccompile.h does the
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.c
int
benchmark(void *tsd, result_t *res)
{
int i = 0;
jmp_buf env;
(void) s
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.c
int
benchmark(void *tsd, result_t *res)
{
int i = 0;
jmp_buf env;
(void) setjmp(env);
