[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] tan compilation problem

From: Camm Maguire
Subject: Re: [Gcl-devel] tan compilation problem
Date: 06 Aug 2002 18:48:02 -0400

Hi Vadim, and thanks for the report!  A fix is always easier than a
good report!!

I've just committed a fix -- please try it out.  The unoptimized
version of tan simply divided cosine into sin, and did not reference
the tan of libm at all, leading to the undefined symbol when the
optimizer replaced our boxed version with the system tan.

I've implemented a new version, which seems just as good as the old,
but did reveal some oddities in gcl's trig stuff.  For example, (cos
(/ pi 2)) is small but not zero.  The original number_tan protected
the tan call by a check that the cosine was not zero.  I left this in,
but it never seems to kick in as cosine is never exactly zero.  I
don't know off the top of my head how to implement the exact trig
results other than simply enumerating them.  Is this important?
Anyone know the right thing to do?

Take care,

"Vadim V. Zhytnikov" <address@hidden> writes:

> Hi!
> I've been trying to figure out why Maxima 5.9.0 (CVS) fails to
> build on gcl 2.5.0 if the latter is build with --enable-bfd
> and it seems to me that I've managed to localize (but not resolve)
> the trouble quite well.
> Let's take very simple file test.lsp which
> contains two almost trivial function definitions
> ------- test.lsp ------------------
> (defun mysin (x)
>      (declare (type double-float x))
>      (sin x))
> (defun mytan (x)
>      (declare (type double-float x))
>      (tan x))
> -----------------------------------
> I build two saved_gcl images. First with --disable-bfd
> and second with --enable-bfd.  When I make
>    (compile-file "tests")
> Not surprisingly resulting test.o is absolutely the same
> for both saved_gcl versions.  nm test.o lists U tan and
> U sin among other symbols.
> The difference reveals when I try to load test.o
>    (load "test")
> First saved_gcl (no bfd) successfully loads the file but
> issues the warning:
>    symbol "tan" is not in base ...
> Notice that it complains about tan but not about sin.
> In spite of successful load mytan doesn't work since
> any attempt to evaluate (mytan ...) results in internal
> lisp error ("memory may be damaged..." and so on).
> On the contrary mysin works fine.
> Second saved_gcl (with bfd) rejects the file with the
> error message:
>    tan is undefined
>    Error: Cannot get relocated section contents
> So bfd-enabled saved_gcl is actually smarter
> and reveals the problem immediately.
> I think that it is not necessary to say that
> if I remove mytan then test.lsp with mysin
> works fine for both saved_gcl images.
> And finally problem disappear if I remove
>    (declare (type double-float x))
> in both function definitions.
> It seems that there is some problem with
> tan in GCL. I wonder why it is so different
> from sin?
> Best wishes,
> Vadim
> -- 
>       Vadim V. Zhytnikov
>        <address@hidden>
>       <address@hidden>
>       <address@hidden>
>      <address@hidden>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]