cmiller@OSCAR.UCAR.EDU (Charlie Miller) (11/17/88)
Hello, I have down-loaded (ftp'd) gcc, installed it per installation
directions and test-compiled a few programs. This is my first
encounter with GNU software and I really appreciate it especially
the quality documentation.
Description of problem: I have either done something stupid (most
likely) or there is a bug in the way some floating point functions are
handled. Should not the compiler make a call to the 68881 when a
function like sin or cos is used? Also when the following program is
compiled and run (same gcc compile line except exclusion of -S and
inclusion of the -lm library flag, see compile line below) the answer
printed out is this: i = NaN
I ran the same program using cc and it seemed to work fine,
including use of 68881 cos function. Also, gcc seems to handle
floating point instructions like division just fine (including 68881
inline calls). Any help on this matter will be greatly appreciated.
Here's the pertinent information:
gcc version: 1.27 (I am using gcc 1.27 is because I want to install g++)
host computer: ISI V24 running UNIX 4.3bsd, M68020 w/M68881
tm.h -> tm-isi68.h
md -> m68k.md
config.h -> config-m68k.h
aux-output.c -> output-m68k.c
gcc compile command line: gcc -m68020 -m68881 -S test.c
(I know the 68020 and 68881 are defaults anyway)
test program:
#include <math.h>
main()
{
double i;
i = cos(.5);
printf("i = %f\n",i);
}
the assembly .s file produced: (notice the fmoved after the jbsr -cos)
#NO_APP
.globl fltused
.text
.even
LC0:
.double 0r0.5
LC1:
.ascii "i = %f\12\0"
.even
.globl _main
_main:
link a6,#-8
movel LC0+4,sp@-
movel LC0,sp@-
jbsr _cos
fmoved fp0,a6@(-8)
movel a6@(-4),sp@-
movel a6@(-8),sp@-
pea LC1
jbsr _printf
L1:
unlk a6
rts
output from gcc -E:
# 1 "test.c"
# 1 "/usr/include/math.h"
extern double asinh(), acosh(), atanh();
extern double erf(), erfc();
extern double exp(), expm1(), log(), log10(), log1p(), pow();
extern double fabs(), floor(), ceil(), rint();
extern double lgamma();
extern double hypot(), cabs();
extern double copysign(), drem(), logb(), scalb();
extern int finite();
extern double j0(), j1(), jn(), y0(), y1(), yn();
extern double sin(), cos(), tan(), asin(), acos(), atan(), atan2();
extern double sinh(), cosh(), tanh();
extern double cbrt(), sqrt();
extern double modf(), ldexp(), frexp(), atof();
# 1 "test.c"
main()
{
double i;
i = cos(.5);
printf("i = %f\n",i);
}
thanks
-charlie
========================================================================
-Charles E. Miller
USPS Mail: High Altitude Observatory
P.O. Box 3000
Boulder CO 80307
Phone: (303) 497-1571
Internet: cmiller@hao.ucar.edu
UUCP: {arizona,decvax,ihnp4}!hao!cmiller
========================================================================purtill@BOURBAKI.MIT.EDU (08/01/89)
gcc version 1.35
example: compiling "makedefs" in the NetHack v3 distribution.
I have the files needed bundled up in a shar file and I can send them
to you, but they amount to almost 200000 characters so I'll only send
them on request.
invocation: add the line "CC=gcc -g" to the makefile provided with
NetHack, and replace the -O in CFLAGS with -traditional. The problem
also occurs if it stays -O or if the -O is just removed.
tm.h -> config/tm-sun3.h
md -> config/m68k
Machine: Sun 3/50.
Operating system: Sun UNIX 4.2 Release 3.5 (DISKLESS)
^^^ NOT 4.0!
Behavior: Invoking "makedefs -p" in the src directory causes a
segmentation fault.
I'm not sure this is a real bug. However, when makedefs is
compiled with Sun's cc, there is no problem -- it works as it should
(no core-dump). However, when I compile with gcc (even with the
-traditional flag), it gets a segmentation violation on line 305 of
makedef.c (according to GDB 3.2). Since the code there looks
perfectly good, my guess is that there is a compiler bug or some very
obscure compiler dependency (in which case, please tell me what it is!)
Note: The NetHack v3 distribution is available from
uunet.uu.net, in directory "comp.sources.games", via anonymous FTP. I
found it in the "new" subdirectory. Alternatively, I can send you
just those files that are needed in a shar format (c 200K).
^.-.^ Mark Purtill purtill@math.mit.edu (617)623-6238 - H
((")) Dept. of Math, MIT 2-229, Cambridge, MA 02139 (617)253-1589 - Ostark@SBCS.SUNYSB.EDU (09/28/89)
We are running GCC v. 1.35.0 on a Sun 3 running Sun OS 3.4. I installed GCC using "tm-sun3.h" and "config/xm-m68k.h". The problem is incorrect code output when compiling a switch statement with a very long body. The source was a y.tab.c generated by bison. I can't send you the source because of the length, but a description of the problem, and some of the generated code should be sufficient. The problem is that GCC evidently fails to use full-word offsets when constructing the dispatch table. The relevant section of code generated for the switch statement is as follows: .stabd 68,0,407 movel d3,d0 subql #1,d0 cmpl #544,d0 jhi L1520 LI1519: movew pc@(L1519-LI1519-2:b,d0:l:2),d0 jmp pc@(2,d0:w) L1519: .word L27-L1519 .word L28-L1519 .word L29-L1519 .word L30-L1519 <very long dispatch table> .word L1507-L1519 .word L1513-L1519 L27: <very long body of switch> L1513: The branch was transferring to random locations when the initial value in d3 got large enough. We patched our "y.tab.s" by editing as follows: LI1519: movel pc@(L1519-LI1519-2:b,d0:l:4),d0 jmp pc@(2,d0:l) L1519: .long L27-L1519 .long L28-L1519 <etc> I wasn't sure if there was supposed to be a flag or pragma to handle such a long switch correctly, but I suspect not, since a quick look at the machine description file appears to show a hard-wired ".word" in the macro to output the cases of a switch. If I am missing something, I would really appreciate it if you would tell me what it is. Thanks. Gene Stark stark@sbcs.sunysb.edu