* bug in throw.c
@ 2003-04-07 0:01 David Mosberger-Tang
2003-04-08 6:31 ` Christopher Cramer
2003-04-11 3:24 ` Rob Browning
0 siblings, 2 replies; 6+ messages in thread
From: David Mosberger-Tang @ 2003-04-07 0:01 UTC (permalink / raw)
Hi,
Today I tried to build guile-1.6.3 on ia64 linux but it failed during
the build when trying to use guile to generate some documentation.
Subsequently, I tried the snapshot from April 4th and it had the same
problem. The problem is quite obvious: in throw.c, we find:
#if 0/*def __GNUC__*/
/* Dirk:FIXME:: This bugfix should be removed some time. */
/* GCC 2.95.2 has a bug in its optimizer that makes it generate
incorrect code sometimes. This barrier stops it from being too
clever. */
asm volatile ("" : "=g" (winds));
#endif
This is clearly bogus: the asm statement claims that it's writing the
"winds" variable, which isn't true. On ia64, this has the effect that
the "winds" gets corrupted and comes out with value "1". Just
disabling the workaround fixes the issue. Perhaps the workaround is
legitimate for some platforms, but I suspect it should always be
disabled for gcc v3.x or newer.
--david
--- libguile/throw.c~ Thu Mar 14 16:00:40 2002
+++ libguile/throw.c Sun Apr 6 16:56:58 2003
@@ -622,7 +622,7 @@
}
}
-#ifdef __GNUC__
+#if 0/*def __GNUC__*/
/* Dirk:FIXME:: This bugfix should be removed some time. */
/* GCC 2.95.2 has a bug in its optimizer that makes it generate
incorrect code sometimes. This barrier stops it from being too
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in throw.c
2003-04-07 0:01 bug in throw.c David Mosberger-Tang
@ 2003-04-08 6:31 ` Christopher Cramer
2003-04-08 6:44 ` David Mosberger-Tang
2003-04-11 3:24 ` Rob Browning
1 sibling, 1 reply; 6+ messages in thread
From: Christopher Cramer @ 2003-04-08 6:31 UTC (permalink / raw)
Cc: guile-devel
On Sun, Apr 06, 2003 at 05:01:36PM -0700, David Mosberger-Tang wrote:
> #if 0/*def __GNUC__*/
> /* Dirk:FIXME:: This bugfix should be removed some time. */
> /* GCC 2.95.2 has a bug in its optimizer that makes it generate
> incorrect code sometimes. This barrier stops it from being too
> clever. */
> asm volatile ("" : "=g" (winds));
> #endif
>
> This is clearly bogus: the asm statement claims that it's writing the
> "winds" variable, which isn't true. On ia64, this has the effect that
> the "winds" gets corrupted and comes out with value "1". Just
Now, I haven't checked up on the changes in recent GCC versions, but
that behavior seems really odd to me. How does it change the value of a
variable if you put in an empty asm statement that only claims to change
the variable?
This is a common tactic to defeat the optimizer. I don't understand
why GCC would suddenly have problems with this.
--
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"People said it couldn't be that our soldiers would do such things. Now
you read worse things in the mainstream media and people don't care. We
used to say that if only people know about it, it would stop. Now they
know about it, and it hasn't stopped." - Adam Keller
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in throw.c
2003-04-08 6:31 ` Christopher Cramer
@ 2003-04-08 6:44 ` David Mosberger-Tang
0 siblings, 0 replies; 6+ messages in thread
From: David Mosberger-Tang @ 2003-04-08 6:44 UTC (permalink / raw)
Cc: David.Mosberger
>>>>> On Tue, 8 Apr 2003 01:31:06 -0500, Christopher Cramer <crayc@pyro.net> said:
Christopher> On Sun, Apr 06, 2003 at 05:01:36PM -0700, David
Christopher> Mosberger-Tang wrote:
>> #if 0/*def __GNUC__*/ /* Dirk:FIXME:: This bugfix should be
>> removed some time. */ /* GCC 2.95.2 has a bug in its optimizer
>> that makes it generate incorrect code sometimes. This barrier
>> stops it from being too clever. */ asm volatile ("" : "=g"
>> (winds)); #endif
>> This is clearly bogus: the asm statement claims that it's writing
>> the "winds" variable, which isn't true. On ia64, this has the
>> effect that the "winds" gets corrupted and comes out with value
>> "1". Just
Christopher> Now, I haven't checked up on the changes in recent GCC
Christopher> versions, but that behavior seems really odd to me. How
Christopher> does it change the value of a variable if you put in an
Christopher> empty asm statement that only claims to change the
Christopher> variable?
Christopher> This is a common tactic to defeat the optimizer. I
Christopher> don't understand why GCC would suddenly have problems
Christopher> with this.
asm volatile ("" : "=g"(winds))
tells the compiler that the old value of "winds" is dead. It is
therefore free to use any register for holding the "new" value of
"winds" which is supposedly produced by the "asm volatile" statement.
--david
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug in throw.c
2003-04-07 0:01 bug in throw.c David Mosberger-Tang
2003-04-08 6:31 ` Christopher Cramer
@ 2003-04-11 3:24 ` Rob Browning
2003-05-03 21:47 ` Marius Vollmer
1 sibling, 1 reply; 6+ messages in thread
From: Rob Browning @ 2003-04-11 3:24 UTC (permalink / raw)
Cc: guile-devel
davidm@mostang.com (David Mosberger-Tang) writes:
> Today I tried to build guile-1.6.3 on ia64 linux but it failed during
> the build when trying to use guile to generate some documentation.
> Subsequently, I tried the snapshot from April 4th and it had the same
> problem. The problem is quite obvious: in throw.c, we find:
>
> #if 0/*def __GNUC__*/
> /* Dirk:FIXME:: This bugfix should be removed some time. */
> /* GCC 2.95.2 has a bug in its optimizer that makes it generate
> incorrect code sometimes. This barrier stops it from being too
> clever. */
> asm volatile ("" : "=g" (winds));
> #endif
>
> This is clearly bogus: the asm statement claims that it's writing the
> "winds" variable, which isn't true. On ia64, this has the effect that
> the "winds" gets corrupted and comes out with value "1". Just
> disabling the workaround fixes the issue. Perhaps the workaround is
> legitimate for some platforms, but I suspect it should always be
> disabled for gcc v3.x or newer.
Interesting. I tracked down the same problem, but thought it was
because the optimizer was being clever with some other code that was
using macros to mess with object internals, and inadvertently hiding
the top-level object from the GC. I fixed it by adding a
scm_remember_upto_here_1 (winds)
just after the abort (), but your explanation makes sense. So if we
remove the asm, do we know if we still need a scm_remember_upto_here_1
(winds) to fix the problem Dirk was initially addressing (and would
that fix it)?
--
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] 6+ messages in thread
* Re: bug in throw.c
2003-04-11 3:24 ` Rob Browning
@ 2003-05-03 21:47 ` Marius Vollmer
2003-05-03 21:56 ` Marius Vollmer
0 siblings, 1 reply; 6+ messages in thread
From: Marius Vollmer @ 2003-05-03 21:47 UTC (permalink / raw)
Cc: David.Mosberger
Rob Browning <rlb@defaultvalue.org> writes:
> davidm@mostang.com (David Mosberger-Tang) writes:
>
> > Today I tried to build guile-1.6.3 on ia64 linux but it failed during
> > the build when trying to use guile to generate some documentation.
> > Subsequently, I tried the snapshot from April 4th and it had the same
> > problem. The problem is quite obvious: in throw.c, we find:
> >
> > #if 0/*def __GNUC__*/
> > /* Dirk:FIXME:: This bugfix should be removed some time. */
> > /* GCC 2.95.2 has a bug in its optimizer that makes it generate
> > incorrect code sometimes. This barrier stops it from being too
> > clever. */
> > asm volatile ("" : "=g" (winds));
> > #endif
> >
> > This is clearly bogus: the asm statement claims that it's writing the
> > "winds" variable, which isn't true. On ia64, this has the effect that
> > the "winds" gets corrupted and comes out with value "1". Just
> > disabling the workaround fixes the issue. Perhaps the workaround is
> > legitimate for some platforms, but I suspect it should always be
> > disabled for gcc v3.x or newer.
>
> Interesting. I tracked down the same problem, but thought it was
> because the optimizer was being clever with some other code that was
> using macros to mess with object internals, and inadvertently hiding
> the top-level object from the GC. I fixed it by adding a
>
> scm_remember_upto_here_1 (winds)
>
> just after the abort (), but your explanation makes sense. So if we
> remove the asm, do we know if we still need a scm_remember_upto_here_1
> (winds) to fix the problem Dirk was initially addressing (and would
> that fix it)?
(I did the original fix, not Dirk, so I'm to blame here.)
The original fix is only needed for GCC 2.95.2 and there only for
i386, probably.
I would say it is safe now to just remove the asm bogosity, as has
already been done in the 1.6 branch.
I will port he 1.6 changes to the 1.7 series.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-05-03 21:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-07 0:01 bug in throw.c David Mosberger-Tang
2003-04-08 6:31 ` Christopher Cramer
2003-04-08 6:44 ` David Mosberger-Tang
2003-04-11 3:24 ` Rob Browning
2003-05-03 21:47 ` Marius Vollmer
2003-05-03 21:56 ` Marius Vollmer
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).