* 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).