From: Richard M K. <kr...@pr...> - 2009-02-06 17:57:09
|
=?iso-8859-1?q?G=E1bor_Melis?= writes: > I'm planning to commit it in a week, until then you may want to test = > > some of the untested builds: > - anything with *BSD Dunno if old gcc versions matter to anyone, but using gcc 3.3.3 on a NetBSD/x86 3.0 I have around, compilation ends here: -- cc -g -Wall -O2 -I. -c -o alloc.o alloc.c pseudo-atomic.h: In function `pa_alloc': pseudo-atomic.h:45: warning: asm operand 0 probably doesn't match constraints pseudo-atomic.h:56: warning: asm operand 0 probably doesn't match constraints pseudo-atomic.h:45: error: impossible constraint in `asm' pseudo-atomic.h:56: error: impossible constraint in `asm' pseudo-atomic.h: In function `set_pseudo_atomic_atomic': pseudo-atomic.h:45: warning: asm operand 0 probably doesn't match constraints pseudo-atomic.h: In function `clear_pseudo_atomic_atomic': pseudo-atomic.h:56: warning: asm operand 0 probably doesn't match constraints pseudo-atomic.h: In function `set_pseudo_atomic_interrupted': pseudo-atomic.h:74: warning: asm operand 0 probably doesn't match constraints pseudo-atomic.h: In function `clear_pseudo_atomic_interrupted': pseudo-atomic.h:85: warning: asm operand 0 probably doesn't match constraints gmake: *** [alloc.o] Error 1 gmake: Leaving directory `/home/kreuter/lsp/imp/sbcl-gabor/src/runtime' -- By inspection, the build succeeds on a NetBSD/x86 4.0 with a newer gcc. Regards, Richard |
From: Gábor M. <me...@re...> - 2009-02-07 13:00:58
|
On Viernes 06 Febrero 2009, Richard M Kreuter wrote: > =?iso-8859-1?q?G=E1bor_Melis?= writes: > > I'm planning to commit it in a week, until then you may want to > > test = > > > > some of the untested builds: > > - anything with *BSD > > Dunno if old gcc versions matter to anyone, but using gcc 3.3.3 on a > NetBSD/x86 3.0 I have around, compilation ends here: > > -- > cc -g -Wall -O2 -I. -c -o alloc.o alloc.c > pseudo-atomic.h: In function `pa_alloc': > pseudo-atomic.h:45: warning: asm operand 0 probably doesn't match > constraints pseudo-atomic.h:56: warning: asm operand 0 probably > doesn't match constraints pseudo-atomic.h:45: error: impossible > constraint in `asm' > pseudo-atomic.h:56: error: impossible constraint in `asm' > pseudo-atomic.h: In function `set_pseudo_atomic_atomic': > pseudo-atomic.h:45: warning: asm operand 0 probably doesn't match > constraints pseudo-atomic.h: In function > `clear_pseudo_atomic_atomic': > pseudo-atomic.h:56: warning: asm operand 0 probably doesn't match > constraints pseudo-atomic.h: In function > `set_pseudo_atomic_interrupted': pseudo-atomic.h:74: warning: asm > operand 0 probably doesn't match constraints pseudo-atomic.h: In > function `clear_pseudo_atomic_interrupted': pseudo-atomic.h:85: > warning: asm operand 0 probably doesn't match constraints gmake: *** > [alloc.o] Error 1 > gmake: Leaving directory > `/home/kreuter/lsp/imp/sbcl-gabor/src/runtime' -- > > By inspection, the build succeeds on a NetBSD/x86 4.0 with a newer > gcc. > > Regards, > Richard The "i" constraint was somewhat optimistic, it relied on the compiler figuring out that make_fixnum(1) is a constant which breaks on gcc 3 and alos on gcc 4 with -O0. Fix pushed. Do the tests run happily? Thanks, Gabor |
From: Josh E. <jo...@el...> - 2009-02-08 23:05:48
|
On Sat, Feb 07, 2009 at 02:00:46PM +0100, G?bor Melis wrote: > The "i" constraint was somewhat optimistic, it relied on the compiler > figuring out that make_fixnum(1) is a constant which breaks on gcc 3 > and alos on gcc 4 with -O0. > > Fix pushed. Do the tests run happily? It builds and runs on OpenBSD (x86), except two of the timer.impure.lisp fail, (:TIMER :STRESS) and (:WITH-TIMEOUT :TIMEOUT). For whatever reason, changing the (sleep 2) in the stress test to (sleep 5) allows both tests to pass. |
From: Gábor M. <me...@re...> - 2009-02-09 08:15:06
|
On Lunes 09 Febrero 2009, Josh Elsasser wrote: > On Sat, Feb 07, 2009 at 02:00:46PM +0100, G?bor Melis wrote: > > The "i" constraint was somewhat optimistic, it relied on the > > compiler figuring out that make_fixnum(1) is a constant which > > breaks on gcc 3 and alos on gcc 4 with -O0. > > > > Fix pushed. Do the tests run happily? > > It builds and runs on OpenBSD (x86), except two of the > timer.impure.lisp fail, (:TIMER :STRESS) and (:WITH-TIMEOUT > :TIMEOUT). For whatever reason, changing the (sleep 2) in the stress > test to (sleep 5) allows both tests to pass. Thank you for the feedback. I can see how a very slow system or more likely one with a low resolution system clock can fail to finish the stress test in time. But the (:with-timeout :timeout) test is not sensitive to that, maybe it failed because the timers from the stress test were still triggerring. In general, it's hard to write reliable timer tests because system load, clock resolution affect them. |
From: Josh E. <jo...@el...> - 2009-02-09 16:40:43
|
On Mon, Feb 09, 2009 at 09:14:52AM +0100, G?bor Melis wrote: > On Lunes 09 Febrero 2009, Josh Elsasser wrote: > > On Sat, Feb 07, 2009 at 02:00:46PM +0100, G?bor Melis wrote: > > > The "i" constraint was somewhat optimistic, it relied on the > > > compiler figuring out that make_fixnum(1) is a constant which > > > breaks on gcc 3 and alos on gcc 4 with -O0. > > > > > > Fix pushed. Do the tests run happily? > > > > It builds and runs on OpenBSD (x86), except two of the > > timer.impure.lisp fail, (:TIMER :STRESS) and (:WITH-TIMEOUT > > :TIMEOUT). For whatever reason, changing the (sleep 2) in the stress > > test to (sleep 5) allows both tests to pass. > > Thank you for the feedback. I can see how a very slow system or more > likely one with a low resolution system clock can fail to finish the > stress test in time. But the (:with-timeout :timeout) test is not > sensitive to that, maybe it failed because the timers from the stress > test were still triggerring. > > In general, it's hard to write reliable timer tests because system load, > clock resolution affect them. OpenBSD has HZ at 100 by default, I'd imagine Linux defaults to 1000 or something even larger. CPU speed was certainly not an issue, this was a very fast box that was almost entirely idle for the several seconds it took for all the timers to trigger. When I isolated those two tests and traced the SIGALRM callback function it did indeed appear that the timers from the stress test affected the (:with-timeout :timeout) test. |