Re: floating point library problems ...

Re: floating point library problems ...

[David Williams]

Make sure that you have dynamic memory (heap) initialised properly. The
floating
point conversion in printf requires a small amount of dynamic memory to
do the
conversion. So if you assume that because you dont use any dynamic
memory that you
do not need to initialise then think again or don't do any floating
point
conversions in printf (or its variants sprintf, vprintf etc.). I have
fallen for
this one myself (on 68EZ328!).

Good Luck
Dave Williams
DragonBall Developers Lair
( http://www.ozemail.com.au/~davidwilliams/ddl_home.htm )

Ken DESMET wrote:

> Thanks to Luke, Greg, Philip and Kai for the your comments and suggestions.
> In the mean time this perticular problem is more or less solved. When I
> compiled the C sources I used it with the -m68000 flag to indicate to
> produce the 16 bit code (my target is an MC68VZ328). But I had not added the
> flag to the linker stage (that was stupid of course), and thus the linker
> used the default 32 bit libraries (for 68020 and onward). That whas the
> reason why multply worked and sin() and sqrt() functions not.
>
> Now my floating point functions work fine, however i an intresting situation
> whyle printing out the floating point value appears.
>
> void test(void)
>  {
>   double fpval;
>
>   fpval = sqrt(M_PI);
>   printf("sqrt(M_PI) = %f\n",fpval);
>  }
>
> The results I get are "sqrt(M_PI) = 1.>?LMMd", the "772454" has been
> transformed into ">?LMMd" and thus unreadable.
>
> Then I modified the program so that it would print out the abtained value as
> an integer number that has been multiplyed with 1000000.
>
> void test(void)
>  {
>   double fpval;
>   int intval;
>
>   fpval = sqrt(M_PI);
>   printf("sqrt(M_PI) = %f\n",fpval);
>   intval = fpval * 1000000;
>   printf("intval = %d.\n",intval);
>  }
>
> The output (is correct this time):
>
> sqrt(M_PI) = 1.772454
> intval = 1772453.
>
> Why is the floating point printed out correcty when a integer operation
> follows (when I remove the integer part i get unreadable decimal part) ?
>
> An interesting detail is the following: The values are printer out on an a
> graphic LCD screen (which works fine). When a floating point fuction is
> called, some dotted lines appeare on the screen, indicating that the program
> writes data somewhere in the LCD framebuffer memory when it should not. I
> have checked the memory map, an this should not happen. I think that
> somthing to do with the floating point subroutines is not properly
> initialised. But what ? ...
>
> Kind regards,
>
> Ken
>
> -----Original Message-----
> From: lgd@virata.com [ mailto:lgd@virata.com]On Behalf Of Luke Diamand
> Sent: donderdag 14 september 2000 13:32
> To: ken@sdt.be
> Cc: crossgcc@sourceware.cygnus.com
> Subject: Re: floating point library problems ...
>
> Could you have some kind of problem with the endianness of doubles? See
> if you get the same problem with floats and work from there.
>
> At least on ARM, gcc assumes doubles are big-endian (the words are in
> the opposite order to the one you would expect, but within a word they
> are little endian). These leads to some weird results for the unwary...
>
> Luke Diamand
>
> Ken DESMET wrote:
> >
> > Hi all,
> >
> > I have build a cross compiler to a m68k target with the newlib-1.8.1
> > library.
> >
> > When i compile small test programs with simple floating point functions
> like
> > multiplications, they do work fine. More complex floating point functions
> > like sqrt() and sin() do not seem to function. They simply hang/never
> return
> > ...
> >
> > Any suggestions what could be the cause of this problem ?
> >
> > Greetings,
> >
> > Ken
>
> --
> Virata http://www.virata.com
> Cambridge
> Tel: +44 1223 566919      Fax: +44 1223 566915
>
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

i686-pc-cygwin to mips64orion-elf cross compiler

[Jeff Domogala]

I've been attempting to build a i686-pc-cygwin to mips64orion-elf cross
compiler with cygwin 1.1.4 installed.  I have run into a series of issues
along the way, and I am still stuck at this point.

I originally attempted to build the cross compiler using the following
cygwin tree components from 1.1.4:
  binutils-20000722-1
  gcc-2.95.2-2.

The parameters I used with configure for binutils and gcc are:
--host=i686-pc-cygwin --target=mips64orion-elf --prefix=/gcc-mips --with
gnu-ld --with-gnu-as -v

I built binutils with: make all install.  There were no errors.
I then put $prefix/bin in $PATH so gcc could find the target specific
utilities.

I then built gcc with: make all LANGUAGES="C C++" install.

The first problem I had was a prototype conflict for make_temp_file():

gcc -c -DCROSS_COMPILE -DIN_GCC     -g -O2  -DHAVE_CONFIG_H    -I. -I../../g
cc-2.95.2-2/gcc -I../../gcc-2.95.2-2/gcc/config -I../../gcc-2.95.2-2/gcc/../
include../../gcc-2.95.2-2/gcc/config/mips/mips.c
../../gcc-2.95.2-2/gcc/config/mips/mips.c:96: conflicting types for
`make_temp_file'
../../gcc-2.95.2-2/gcc/../include/libiberty.h:69: previous declaration of
`make_temp_file'
make[1]: *** [mips.o] Error 1
make[1]: Leaving directory `/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc'
make: *** [all-gcc] Error 2

I commented out the offending prototype in
gcc-2.95.2-2/gcc/../include/libiberty.h:69 since its return type was
different than the rest of the mips routines.

The second make gcc make attempt produced the following error:

Testing libgcc1.  Ignore linker warning messages.
/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95
.2-2/gcc/ -B/gcc-mips-cygwin/mips64orion-elf/bin/ -I/gcc-mips-cygwin/mips64o
rion-elf/include -DCROSS_COMPILE -DIN_GCC     -g -O2 -I./include
libgcc1-test.o -o libg
cc1-test \
  -nostartfiles -nostdlib
`/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.9
5.2-2/gcc/ -B/gcc-mips-cygwin/mips64orion-elf/bin/ -I/gcc-mips-cygwin/mips64
orion-elf/include --print-libgcc-file-name`
collect2: ld terminated with signal 11 [Segmentation fault]
      0 [main] ld 8214 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
  16956 [main] ld 8214 stackdump: Dumping stack trace to ld.exe.stackdump
make[1]: *** [libgcc1-test] Error 1
make[1]: Leaving directory `/cygdrive/d/gnu/build-gcc-2.95.2-2/gcc'
make: *** [all-gcc] Error 2

Here's the contents of the stack trace file:
Exception: STATUS_ACCESS_VIOLATION at eip=0045B901
eax=00000002 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000001
ebp=0259F800 esp=0259FAB8
program=D:\cygwin\gcc-mips-cygwin\mips64orion-elf\bin\ld.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0259F800  0045B901  (00000000, 00000000, 00000000, 00000000)
0259FB20  0045B901  (0A060588, 004914AC, 0A060CD8, 0A061D30)
0259FC80  0043E508  (0A060588, 004914AC, 0259FCE0, 00000000)
0259FCA0  0043BDAA  (0A060588, 004914AC, 0259FCDC, 6102285E)
0259FCE0  004135A3  (0A052B00, 0259FD28, 0259FD30, 00413FFA)
0259FD30  00414004  (0A052A60, 00000000, 0259FD70, 00417ACE)
0259FD70  00417AE8  (0A0529D8, 0A051CA8, 00000000, 6103EF38)
0259FDA0  0041ADF4  (00000008, 0A0529D8, 0A051CA8, 61002241)
0259FF10  61002272  (FFFFFFFF, 00000000, 77F763D3, 77F763DB)
0259FF70  61002805  (0041A758, 00000000, 0259FFA0, 0048C89D)
0259FF80  61002843  (00000000, 00000000, 00000000, 00000000)
0259FFA0  0048C89D  (0041A758, 81491460, 81491300, 77F1B9E7)
0259FFC0  00401035  (00000000, 00000000, 7FFDF000, 7FFDF000)
0259FFF0  77F1B9EA  (00401000, 00000000, 000000B0, 00000100)
End of stack trace

I gave up at this point with this setup but would like some direction, if
there is somewhere I can go with this.  It looks to me like the linker is
hosed for mips.

I decided to attempt to build a cross compiler from a non-cygnus tree.

I used binutils-2.10 and gcc-2.95.2 this time and use the same configuration
options (after wiping out the previous attempt of course).  I built binutils
without a hitch and the build of gcc did not require the header file
modification.  But, this time I got the following while building gcc:

make[2]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/lib
io'
cd ../libiberty ; make "SHELL=/bin/sh" "INSTALL=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c" "INSTALL_DATA=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c -m 644" "INSTALL_PROGRAM=/bin/sh
/cygdrive/d/gnu/gcc-2.95.2/install-sh -c " "prefix=/gcc-mips"
"exec_prefix=/gcc-mips" "tooldir=/gcc-mips/mips64orion-elf"
"gxx_include_dir=/gcc-mips/include/g++-3"
"libsubdir=/gcc-mips/lib/gcc-lib/mips64orion-elf/2.95.2"
"gcc_version=2.95.2"
"gcc_version_trigger=/cygdrive/d/gnu/gcc-2.95.2/gcc/version.c"
"AR=mips64orion-elf-ar" "AR_FLAGS=rc"
"CC=/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.
95.2/gcc/ -B/gcc-mips/mips64orion-elf/bin/"
"CXX=/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2
.95.2/gcc/ -B/gcc-mips/mips64orion-elf/bin/" "CFLAGS=-g -O2"
"CXXFLAGS=-g -O2" "NM=mips64orion-elf-nm" "RANLIB=mips64orion-elf-ranlib"
"LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "LOADLIBES="
"LDFLAGS="
"MAKEINFO=/cygdrive/d/gnu/build-gcc-2.95.2/texinfo/makeinfo/makeinfo "
"SHLIB=libstdc++.so.2.10.0" "SHCURSES=" "RUNTESTFLAGS="
make[2]: Entering directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
make[1]: *** [../libiberty/libiberty.a] Error 2
make[1]: Leaving directory
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libstdc++'
make: *** [all-target-libstdc++] Error 2

Here is the contents of config.log from
`/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty':
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:591: checking host system type
configure:614: checking build system type
configure:640: checking for mips64orion-elf-ar
configure:672: checking for mips64orion-elf-ranlib
configure:749: checking for gcc
configure:828: checking whether we are using GNU C
configure:837:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E conftest.c
configure:852: checking whether
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ accepts -g
configure:881: checking for POSIXized ISC
configure:919: checking for a BSD compatible install
configure:980: checking how to run the C preprocessor
configure:1001:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/file.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/param.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for stdlib.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for string.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for unistd.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for strings.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/time.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1063: checking for sys/resource.h
configure:1073:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -E  conftest.c >/dev/null
2>conftest.out
configure:1100: checking for sys/wait.h that is POSIX.1 compatible
configure:1121:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -c -g -O2  conftest.c 1>&5
configure:1749: checking whether the C compiler
(/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.
2/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -g -O2 ) works
configure:1765:
/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -o conftest -g -O2   conftest.c  1>&5
/gcc-mips/mips64orion-elf/bin/ld: cannot open crt0.o: No such file or
directory
collect2: ld returned 1 exit status
configure: failed program was:

#line 1760 "configure"
#include "confdefs.h"

main(){return(0);}

It looks like to me that I need crt0.o for ld to work correctly.  So, how do
I create this file and does it have to be made for the host or the target?
It is not addresses in the crossgcc FAQ.

One last thing...  I was assuming that I did not need to build a native
toolchain with the non-cygnus tree before I built the cross compiler.  Is
this a correct assumption?  I read the entire crossgcc FAQ and did not see
an answer to this question.

Any help would be greatly appreciated.

Thanks,

Jeff Domogala


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: i686-pc-cygwin to mips64orion-elf cross compiler

[Kai Ruottu]

Jeff Domogala wrote:
> 
> I've been attempting to build a i686-pc-cygwin to mips64orion-elf cross
> compiler with cygwin 1.1.4 installed.  I have run into a series of issues
> along the way, and I am still stuck at this point.
> 
> I used binutils-2.10 and gcc-2.95.2 this time and use the same configuration
> options (after wiping out the previous attempt of course).  I built binutils
> without a hitch and the build of gcc did not require the header file
> modification.  But, this time I got the following while building gcc:
> make[2]: Entering directory
> `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty'
> make[2]: *** No targets specified and no makefile found.  Stop.
> 
> Here is the contents of config.log from
> `/cygdrive/d/gnu/build-gcc-2.95.2/mips64orion-elf/libiberty':
>
> configure:1749: checking whether the C compiler
> (/cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.
> 2/gcc/ -B/gcc-mips/mips64orion-elf/bin/ -g -O2 ) works

 The words 'C compiler' are wrong here, it really means 'toolset' or something
more bigger than just the compiler, ie. the assembler, linker, startup-routine
(crt0.o), C-library (libc.a), linker script etc. are checked before trying
libiberty.

 So your GCC compiler (in the 'gcc' subdir)  most probably works now, you can
compile a C-file into assembly with it (-S), use the target 'as' to produce an
object file, '.o' (-c) etc. But you cannot yet link without the startup-routine
(crt0.o) and without proper C-libraries (lib*.a)...

> configure:1765:
> /cygdrive/d/gnu/build-gcc-2.95.2/gcc/xgcc -B/cygdrive/d/gnu/build-gcc-2.95.2
> /gcc/ -B/gcc-mips/mips64orion-elf/bin/ -o conftest -g -O2   conftest.c  1>&5
> /gcc-mips/mips64orion-elf/bin/ld: cannot open crt0.o: No such file or
> directory
> 
> It looks like to me that I need crt0.o for ld to work correctly.  So, how do
> I create this file and does it have to be made for the host or the target?

 The startup-routine belongs into your C-libraries and is a part of the Cygnus
newlib. The newlib includes some startups, either in the libgloss/mips (or in the
newlib/libc/sys/mips) for the supported target boards.

 I refer to my another message about the 'Makefile.in' fixes, whether to build
newlib at the same time with GCC, or to just pre-install the newlib ('target')
headers, as the GCC-manual suggests, then build only GCC using 'make all-gcc'
or something, install GCC and then build newlib separately, install it, fix
the 'specs' for GCC (see later) so that one can link and produce a simple
"Hello World" executable with GCC + newlib etc. And when everything seems to
work, to let the 'GCC build' try the same before building libiberty & Co...

 Doing things one at a time and trying to understand what the separate tools
really do while 'compiling', e.g. that the 'xgcc + cpp + cc1'-chain produces
only assembly for 'as'. Trying the '-v' with the native GCC tells quite a lot
about the 'compiling phases'.

 In order to produce GCC for the target, one needs only the target headers and
the binutils for the target. Nothing more. For producing executables for the
target one needs the target libs, including the startup-routine.

 So you will need the 'crt0.o' for the 'target' now or later. The first thing to
understand is that you really need a real 'target'... While a 'mips-linux-gnu'
involves a defined startup for Linux/MIPS, known system calls for Linux in its
C-library etc., your 'mips64orion-elf' says only the CPU-type and the object
format, not anything about the I/O-arrangement or 'opsys' in your target board.
There aren't any 'defaults' for these things in the GCC config files...

 Ok, the 'specs'-file has the default options given to the linker, here is a
clip from my 'specs' for 'mips64orion-elf' :

--------------- clip ------------------------
*cc1plus:


*endfile:
crtend%O%s

*link:
%{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{bestGnum} %{shared} %{non_shared} %(linker_endian_spec) -T pmon.ld%s

*lib:
-lc -lpmon -lc

*libgcc:
-lgcc

*startfile:
crtbegin%O%s crt0%O%s

*switches_need_spaces:

--------------- clip ------------------------

 The freely available 'PMON'-monitor on the target board is my default
for the 'opsys', so its linker script 'pmon.ld' and its glue library
(for the low-level-I/O like 'read()', 'write()',...) are defined here.

 Ok, you will have the 'crt0.o' in 'gcc-mips/mips64orion-elf/lib' after
building and installing first GCC, then newlib, and GCC will find it
automatically (because already installed), but if you try the GCC and
newlib at the same time, you haven't the probably needed
  -B/gcc-mips/mips64orion-elf/lib
in the options given to 'xgcc', so the linker doesn't find it because
of the new 'relative search paths' using the:
  $prefix/lib/gcc-lib/$target/$version/../../../../$target/lib
instead of the straight path:
   $prefix/$target/lib

> It is not addresses in the crossgcc FAQ.

 Did you RTFM at all before looking the FAQ ?  "Installation/Cross-Compiler"
in the GCC-manual (> 500 pages) really tells about the 'crt0.o', C-library
for the target etc.

 The most common problem seems to be that people no more ask questions like
"I have GCC but no manual for it, where the hell it is ?". I haven't seen this
'obvious' question asked for a while although all Linux distributions seem to
miss the manual, Cygwin ?, Mingw ? ... The GCC-manual not belonging to a GCC-
distribution ?  Bullshit... (Perhaps the 'gcc.info' is included, but it should
be history...)

 I prefer PDF, so e.g. the RedHat/Cygnus 'Embedded Development Toolkit' (EDK)
at: ftp://ftp.redhat.com/pub/redhat/edk , and the PDF & HTML-manuals with it
(although for 'gcc-2.9-99r1p1') can be suggested, until one builds his/hers
own ones from the GCC-sources using Tex, Ghostscript, texi2html etc.

 Someone described the GCC-manual production process on this list some months
ago... I would consider this skill just as important as producing the toolset
binaries. After the toolset build one should have the binaries and ALSO the
docs for it... The Cross-GCC FAQ addressing the docs-building at all ?

 Hmmm, if I continue critizing the FAQ, not contributing anything to it (how
I could when not agreeing with it?), soon I must write one myself (from all
the answers I have written to this list...). The big problem is that I have
my own NIH-like opinions about the things, not always agreeing with the FAQ... 

> One last thing...  I was assuming that I did not need to build a native
> toolchain with the non-cygnus tree before I built the cross compiler.  Is
> this a correct assumption?  I read the entire crossgcc FAQ and did not see
> an answer to this question.

 Of course you don't need it...
 
 Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: floating point library problems ...

[Ken DESMET]

Thanks to Luke, Greg, Philip and Kai for the your comments and suggestions.
In the mean time this perticular problem is more or less solved. When I
compiled the C sources I used it with the -m68000 flag to indicate to
produce the 16 bit code (my target is an MC68VZ328). But I had not added the
flag to the linker stage (that was stupid of course), and thus the linker
used the default 32 bit libraries (for 68020 and onward). That whas the
reason why multply worked and sin() and sqrt() functions not.

Now my floating point functions work fine, however i an intresting situation
whyle printing out the floating point value appears.

void test(void)
 {
  double fpval;

  fpval = sqrt(M_PI);
  printf("sqrt(M_PI) = %f\n",fpval);
 }

The results I get are "sqrt(M_PI) = 1.>?LMMd", the "772454" has been
transformed into ">?LMMd" and thus unreadable.

Then I modified the program so that it would print out the abtained value as
an integer number that has been multiplyed with 1000000.

void test(void)
 {
  double fpval;
  int intval;

  fpval = sqrt(M_PI);
  printf("sqrt(M_PI) = %f\n",fpval);
  intval = fpval * 1000000;
  printf("intval = %d.\n",intval);
 }

The output (is correct this time):

sqrt(M_PI) = 1.772454
intval = 1772453.

Why is the floating point printed out correcty when a integer operation
follows (when I remove the integer part i get unreadable decimal part) ?

An interesting detail is the following: The values are printer out on an a
graphic LCD screen (which works fine). When a floating point fuction is
called, some dotted lines appeare on the screen, indicating that the program
writes data somewhere in the LCD framebuffer memory when it should not. I
have checked the memory map, an this should not happen. I think that
somthing to do with the floating point subroutines is not properly
initialised. But what ? ...

Kind regards,

Ken

-----Original Message-----
From: lgd@virata.com [ mailto:lgd@virata.com]On Behalf Of Luke Diamand
Sent: donderdag 14 september 2000 13:32
To: ken@sdt.be
Cc: crossgcc@sourceware.cygnus.com
Subject: Re: floating point library problems ...


Could you have some kind of problem with the endianness of doubles? See
if you get the same problem with floats and work from there.

At least on ARM, gcc assumes doubles are big-endian (the words are in
the opposite order to the one you would expect, but within a word they
are little endian). These leads to some weird results for the unwary...


Luke Diamand

Ken DESMET wrote:
>
> Hi all,
>
> I have build a cross compiler to a m68k target with the newlib-1.8.1
> library.
>
> When i compile small test programs with simple floating point functions
like
> multiplications, they do work fine. More complex floating point functions
> like sqrt() and sin() do not seem to function. They simply hang/never
return
> ...
>
> Any suggestions what could be the cause of this problem ?
>
> Greetings,
>
> Ken

--
Virata http://www.virata.com
Cambridge
Tel: +44 1223 566919      Fax: +44 1223 566915


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: floating point library problems ...

[Kai Ruottu]

Ken DESMET wrote:
> 
> I have build a cross compiler to a m68k target with the newlib-1.8.1
> library.
> 
> When i compile small test programs with simple floating point functions like
> multiplications, they do work fine. More complex floating point functions
> like sqrt() and sin() do not seem to function. They simply hang/never return
> ...
> 
> Any suggestions what could be the cause of this problem ?

 Too new sources perhaps?  The egcs-snapshots have behaved like this some time now...
I haven't tried the pure '__addsf3()', '__subsf3()', '__mulsf3', '__divsf3()' etc.
operations from 'libgcc.a' though. Perhaps they work now, but some others like the
conversions not...  Did you rebuild newlib or use the old binaries with the new
compiler?

-------------------------------- clip ------------------------------------------
Subject: Re: h8300: less optimal (buggy?) compiler output with last build
Date:    Mon, 21 Aug 2000 08:34:44 -0600
From:    Jeffrey A Law <law@cygnus.com>
To:      karuottu@freenet.hut.fi
CC:      Kazu Hirata <kazu@hxi.com>, gcc <gcc@gcc.gnu.org>, gnuh8 <gnuh8@pcserv.demon.co.uk>

In message <399D30DE.E0DAAF45@luukku.com>you write:
> Ok, I then tested some simpler float-programs and none of them worked. When
> looking one under GDB, I found it being in eternal loop in 'floatsisf()' in
> '_floatdisf.o'/'libgcc.a'...
This is because one of Jakub's changes has badly broken our 16bit targets.

jeff
-------------------------------- clip ------------------------------------------

 When tried last, the 20000911 weekly snapshots still had this problem.
Looking into the 'gcc-bugs' maillist would tell something more, my tries
say that some targets may work, some still not. The H8/300 and FR30 at
least belong to the 'not' category...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: floating point library problems ...

[Philip Blundell]

>I saw this in basetype.h for ARM. At first I thougth it might be an error. 
>THis could cause some serious confusion. It's hard enough to decipher 
>little-endian in a memory dump, but big-little-endian is just too strange. 
>Is it a standard convention in the ARM world?

Pretty much, at least for the "FPA" ARM floating point implementation.
It results from a historical accident sometime in the late '80s.

I think newer ARM processors (ARM10 and so on) use a more standard format.

p.



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: floating point library problems ...

[Greg Shubin]

I saw this in basetype.h for ARM. At first I thougth it might be an error. THis
could cause some serious confusion. It's hard enough to decipher little-endian in
a memory dump, but big-little-endian is just too strange. Is it a standard
convention in the ARM world?

// Characterize the architecture

#ifdef __ARMEB__
# define CYG_BYTEORDER           CYG_MSBFIRST    // Big endian
#else
# define CYG_BYTEORDER           CYG_LSBFIRST    // Little endian
#endif
#define CYG_DOUBLE_BYTEORDER    CYG_MSBFIRST    // Big? endian


Luke Diamand wrote:

> Could you have some kind of problem with the endianness of doubles? See
> if you get the same problem with floats and work from there.
>
> At least on ARM, gcc assumes doubles are big-endian (the words are in
> the opposite order to the one you would expect, but within a word they
> are little endian). These leads to some weird results for the unwary...
>
> Luke Diamand
>
> Ken DESMET wrote:
> >
> > Hi all,
> >
> > I have build a cross compiler to a m68k target with the newlib-1.8.1
> > library.
> >
> > When i compile small test programs with simple floating point functions like
> > multiplications, they do work fine. More complex floating point functions
> > like sqrt() and sin() do not seem to function. They simply hang/never return
> > ...
> >
> > Any suggestions what could be the cause of this problem ?
> >
> > Greetings,
> >
> > Ken
>
> --
> Virata http://www.virata.com
> Cambridge
> Tel: +44 1223 566919      Fax: +44 1223 566915
>
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: floating point library problems ...

[Luke Diamand]

Could you have some kind of problem with the endianness of doubles? See
if you get the same problem with floats and work from there.

At least on ARM, gcc assumes doubles are big-endian (the words are in
the opposite order to the one you would expect, but within a word they
are little endian). These leads to some weird results for the unwary...


Luke Diamand

Ken DESMET wrote:
> 
> Hi all,
> 
> I have build a cross compiler to a m68k target with the newlib-1.8.1
> library.
> 
> When i compile small test programs with simple floating point functions like
> multiplications, they do work fine. More complex floating point functions
> like sqrt() and sin() do not seem to function. They simply hang/never return
> ...
> 
> Any suggestions what could be the cause of this problem ?
> 
> Greetings,
> 
> Ken

-- 
Virata http://www.virata.com
Cambridge
Tel: +44 1223 566919      Fax: +44 1223 566915

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

floating point library problems ...

[Ken DESMET]

Hi all,

I have build a cross compiler to a m68k target with the newlib-1.8.1
library.

When i compile small test programs with simple floating point functions like
multiplications, they do work fine. More complex floating point functions
like sqrt() and sin() do not seem to function. They simply hang/never return
...

Any suggestions what could be the cause of this problem ?

Greetings,

Ken


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com