Re: [Gcl-devel] Maxima 5.9 CVS with new GCL successfull buld

[Camm Maguire]

Greetings!

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

> Camm Maguire ÐÉÛÅÔ:
> > Greetings!  OK, Vadim, could you please send me the output of the
> > following:
> > 
> > nm raw_gcl |grep -i tan
> 0806e064 T Latan
> 08056f78 T Lconstantp
> 08074154 T Lstandard_char_p
> 0806df98 T Ltan
> 0807230c T bitand
> 08056cf8 T fLconstantp
> 080636b4 T make_constant
> 08063704 T make_si_constant
> 0806d5d8 T number_atan
> 0806d464 T number_atan2
> 0806dd34 T number_tan
> 08208fec B sLAstandard_inputA
> 08209014 B sLAstandard_outputA
> 0824c104 B sLstandard_char
> 0808f870 T setup_standard_READ
> 08085008 T siLAmake_constant
> 080900e8 T siLstandard_readtable
> 082090b4 B standard_io
> 08089c70 T standard_read_object_non_recursive
> 08252694 B standard_readtable
> > nm saved_gcl |grep -i tan
> exactly as above
> > nm f2cl-lib.o |grep -i tan
>           U Latan
>           U Ltan
>           U tan
> > 

OK, this can't be a bfd problem, tan is genuinely undefined.  On my
system, the last 'nm' gives:

intech19:/fix/f/debian/mm/maxima/59/maxima/src/numerical$ nm f2cl-lib.o |grep 
tan
         U Latan
         U Ltan

I've looked at the produced .c, and tan is indeed used apart from
Ltan.  A simple cc -g -c on the .c gives the nm as you've reported.
My hunch is that the second compiler pass optimizes this to a call to
Ltan or some equivalent, and that you are compiling maxima without
full optimization.  Right?  If so, at least you have a workaround, but
we really should address this unoptimized tan possibility in the lisp
compiler.  Or we could write out own little C tan utility.

Take care,

> 
> Vadim
> 
> 
> 
> 

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