Path: utzoo!telly!attcan!uunet!tut.cis.ohio-state.edu!RUTGERS.EDU!cdspr!bbs
From: cdspr!bbs@RUTGERS.EDU (Barry B. Schwartz)
Newsgroups: gnu.gcc.bug
Subject: bug report
Message-ID: <8903140630.AA17202@cdspr>
Date: 14 Mar 89 06:30:37 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 74

I am reporting a possible bug in gcc version 1.34
(and coincidentally version 1.33) for the sun-386i
running SunOS version 4.0.1.

I compiled (but never "installed") gcc 1.34 according to the instructions
in INSTALL, and when I ran the object file comparison test
(both the csh version given and the following bourne shell
version:

for i in *.o
do
	cmp $i stage2/$i
done

) I got many messages to the effect that different stages
of object file were differing in the fifth byte.  I got
a similar result when comparing any two stages of the bootstrap
pairwise, even if I carried out another bootstrap stage.

I tried this with the built-in make, with Gnu make, and with
gnu make and gcc vers. 1.33, and got similar results.  Also
I tried

	gmake bootstrap

(where gmake was the Gnu make) and got similar results.

When I did hex dumps of two of the object files
and compared them, I found differences in bytes 5 and 6 and in
those bytes only.
I found similar results on two different compilations with two
different object code outputs.  I have forgotten what files
were checked in the first pair of hex dumps, but here are the complete
diff outputs from the second pair of hex dumps (od -x):

1c1
< 0000000  014c 0004 fe94 2419 c26a 0000 045e 0000
---
> 0000000  014c 0004 f92e 2419 c26a 0000 045e 0000

The first dump line is for stage 3 of expr.o  (./expr.o), whereas
the second dump line is for stage 2 of expr.o  (./stage2/expr.o).

I tried 
   config.gcc sun386
and
   config.gcc sun386i
(which did the same thing, apparently).
Either way I got similar results.

I never noticed any error messages or warnings during any
of the compilations.

Apparently bison was never invoked.

I was using the standard sun linker (as far as I know).
I changed the makefile definitions of bindir and libdir
to /home/public/bin and /home/public/lib, respectively.
Also, when I used gnu make, i called it gmake and put
the following line in the makefile:

	MAKE = gmake

------------------

If the problem is a bug, I hope I have been helpful.
If it isn't, then I say "Woops!" and do the compilation
correctly when I find out how.  I am curious just how
harmful this problem could be.

Thank you for everything.

Barry Schwartz
cdspr!bbs@rutgers.edu