* powerpc problems at least partially fixed (more optimization issues). [not found] ` <87fzopxal5.fsf@raven.i.defaultvalue.org> @ 2003-04-11 17:33 ` Rob Browning 2003-04-11 18:46 ` Rob Browning 2003-04-12 8:26 ` Kevin Ryde 0 siblings, 2 replies; 3+ messages in thread From: Rob Browning @ 2003-04-11 17:33 UTC (permalink / raw) Cc: guile-devel Rob Browning <rlb@defaultvalue.org> writes: > What's really strange is here's what I get on powerpc with 1.6.3 right > now: > > (display (and 1 2 3 4 5)) (newline) > 4 > > I'm quite confused. Found it. In eval.c this construct: while (SCM_NNULLP (t.arg1 = SCM_CDR (t.arg1))) is apparently not OK. If you rewrite the code to separate the assignment and the test, assigning before the guard and at the end of the loop body, we get the expected result: (display (and 1 2 3 4 5)) (newline) 5 There's an identical construct just after nontoplevel_begin which causes a segfault which you have to fix before you can even test the above. At the moment I don't know if this is a legitimate optimzation interacting badly with our macros/fancy-bit-twiddling, or if it's a bug in gcc, but either way, I'm going to change the code in 1.6 and HEAD. Also I want to amend my comment about the "winds abort problem" before. In throw.c I suggested this as a possible fix (if we still need one): /* If the wind list is malformed, bail. */ if (!SCM_CONSP (winds)) abort (); /* this was added to fix a segfault on ia64 */ scm_remember_upto_here_1 (winds); but if there's any way gcc can know that abort never returns, I wonder if the following might be safer: /* If the wind list is malformed, bail. */ /* "remembers" added to fix a segfault on ia64 */ if (!SCM_CONSP (winds)) { scm_remember_upto_here_1 (winds); abort (); } scm_remember_upto_here_1 (winds); -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: powerpc problems at least partially fixed (more optimization issues). 2003-04-11 17:33 ` powerpc problems at least partially fixed (more optimization issues) Rob Browning @ 2003-04-11 18:46 ` Rob Browning 2003-04-12 8:26 ` Kevin Ryde 1 sibling, 0 replies; 3+ messages in thread From: Rob Browning @ 2003-04-11 18:46 UTC (permalink / raw) Cc: guile-devel Rob Browning <rlb@defaultvalue.org> writes: > Found it. In eval.c this construct: > > while (SCM_NNULLP (t.arg1 = SCM_CDR (t.arg1))) > > At the moment I don't know if this is a legitimate optimzation > interacting badly with our macros/fancy-bit-twiddling, or if it's a > bug in gcc, but either way, I'm going to change the code in 1.6 and > HEAD. Now that I poke around, it looks like changes similar in effect have already been made in 1.7... -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: powerpc problems at least partially fixed (more optimization issues). 2003-04-11 17:33 ` powerpc problems at least partially fixed (more optimization issues) Rob Browning 2003-04-11 18:46 ` Rob Browning @ 2003-04-12 8:26 ` Kevin Ryde 1 sibling, 0 replies; 3+ messages in thread From: Kevin Ryde @ 2003-04-12 8:26 UTC (permalink / raw) Rob Browning <rlb@defaultvalue.org> writes: > > if there's any way gcc can know that abort never returns, glibc tells it that with attribute `noreturn' on the abort prototype. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-04-12 8:26 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87adeykqcc.fsf@raven.i.defaultvalue.org> [not found] ` <873ckqnhk4.fsf@zagadka.ping.de> [not found] ` <87istlbt9c.fsf@raven.i.defaultvalue.org> [not found] ` <87of3dmo7y.fsf@zagadka.ping.de> [not found] ` <87fzopxal5.fsf@raven.i.defaultvalue.org> 2003-04-11 17:33 ` powerpc problems at least partially fixed (more optimization issues) Rob Browning 2003-04-11 18:46 ` Rob Browning 2003-04-12 8:26 ` Kevin Ryde
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).