egcs-1.1b bootstrap comparison failure, i386-pc-solaris2.7
Blake Jones
blakej@junta.Eng.Sun.COM
Tue Oct 13 00:01:00 GMT 1998
> Use gnu-make and I think this problem will go away.
I'll give it a try, thanks.
> This is potentially very serious. It is impossible to tell how serious
> without doing a full analysis.
>
> Unfortunately, I don't have access to any x86-solaris2.7 machines, so
> I can not debug it myself.
Well, I expected this. :) But I'll be glad to give as much help as I can.
> The first step (of course) is to verify that the problem is
> reproducible. If you can't reproduce the problem, then it's going to
> be all but impossible to debug.
It is reproducible. I made a clean directory and configured with:
CC=cc
CFLAGS='-O'
LIBCFLAGS='-g -O2'
LIBCXXFLAGS='-g -O2 -fno-implicit-templates'
export CC CFLAGS LIBCFLAGS LIBCXXFLAGS
/home/kg/src/egcs-1.1b/dist/configure \
--prefix=/home/kg/share/egcs-1.1b \
--exec-prefix=/home/kg/$i386/egcs-1.1b \
--enable-shared \
--without-gnu-as \
--without-gnu-ld \
--enable-version-specific-runtime-libs
(Same as the first time.) I built with GNU make, and didn't use "-j"
as I did the first time. The same files give comparison errors.
> The second step is to select one of these failures to analyze:
I picked f/data.o.
> Typically I select the one with smallest .o file. You'll need cpp
> output for the failing module. You can get this by adding -save-temps
> to the command line which was used to compile the failing module.
> This will have a .i file like g77.i.
I compiled it with:
stage2/xgcc -Bstage2/ -c -DIN_GCC -O2 -O -W -Wall -I. -I.. \
-save-temps -I/home/kg/src/egcs-1.1b/dist/gcc/f \
-I/home/kg/src/egcs-1.1b/dist/gcc/f/.. \
-I/home/kg/src/egcs-1.1b/dist/gcc/f/../config \
/home/kg/src/egcs-1.1b/dist/gcc/f/data.c
which I took right from the build typescript.
> Then you want to do something like
>
> stage1/cc1 -O2 -g g77.i -o foo.s
> stage2/cc1 -O2 -g g77.i -o bar.s
>
> The .s files should be different.
Indeed, they are.
> The next step will be to add "-dap" to those command lines which force
> the compiler to emit debugging dumps. You'll want to compare the
> debugging dumps and find the first one that is different.
It's already different in the .rtl file. From my glances at the man
pages, and from the relative timestamps of the files, that looks like
the first one generated. (Obviously, I'm not familiar with gcc
internals.) All the dump files are different except *.sched and *.bp,
which it looks like is to be expected.
I compiled them with "stageN/cc1 -O2 data.i -dap -o data.s".
The diffs in the *.rtl files are:
10083c10083
< (zero_extend:HI (reg:QI 61))) -1 (nil)
---
> (zero_extend:HI (reg:QI 66))) -1 (nil)
10087c10087
< (zero_extend:HI (reg:QI 66))) -1 (nil)
---
> (zero_extend:HI (reg:QI 61))) -1 (nil)
10092,10093c10092,10093
< (udiv:HI (reg:HI 70)
< (reg:HI 71)))
---
> (udiv:HI (reg:HI 71)
> (reg:HI 70)))
10095,10096c10095,10096
< (umod:HI (reg:HI 70)
< (reg:HI 71)))
---
> (umod:HI (reg:HI 71)
> (reg:HI 70)))
14178c14178
< (zero_extend:HI (reg:QI 113))) -1 (nil)
---
> (zero_extend:HI (reg:QI 118))) -1 (nil)
14182c14182
< (zero_extend:HI (reg:QI 118))) -1 (nil)
---
> (zero_extend:HI (reg:QI 113))) -1 (nil)
14187,14188c14187,14188
< (udiv:HI (reg:HI 122)
< (reg:HI 123)))
---
> (udiv:HI (reg:HI 123)
> (reg:HI 122)))
14190,14191c14190,14191
< (umod:HI (reg:HI 122)
< (reg:HI 123)))
---
> (umod:HI (reg:HI 123)
> (reg:HI 122)))
I expect that's not any help at all, and I expect context diffs (other
than the "context" of the whole file) wouldn't be any more helpful. The
data.i file is 243K, and the data.i.rtl file is 437K, which is why I
didn't include them in this mail. I can put any number of the files up
on an FTP site, or if you want, I can gzip/uuencode/mail them to you.
I suspect that the cc1 binaries would run on a x86 Solaris 2.6 system
(if you have access to one); if that would help, I can get you the
respective cc1's also.
Thanks for your help.
Blake
More information about the Gcc-bugs
mailing list