bug in throw.c

bug in throw.c

[David Mosberger-Tang]

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

Re: bug in throw.c

[Christopher Cramer]

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

Re: bug in throw.c

[David Mosberger-Tang]

>>>>> 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

Re: bug in throw.c

[Rob Browning]

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

Re: bug in throw.c

[Marius Vollmer]

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

Re: bug in throw.c

[Marius Vollmer]

Marius Vollmer <mvo@zagadka.de> writes:

> I will port the 1.6 changes to the 1.7 series.

Well, I just removed the asm statement for now... let's see what
happens.

-- 
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