>> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> Now, if you can isolate the relevant part of the diff between
> 2.95.2 and RH 2.96...
Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and
% /usr/bin/gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
0x84800000
% /usr/gcc/aeb/bin/gcc -v
Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
0x0
So, not all versions of gcc 2.95.2 are equal.
% rpm -qf /usr/bin/gcc
gcc-2.95.2-51
This is from a SuSE distribution, I forget which, not very recent.
Revised summary: gcc-2.95.2-51 from SuSE is buggy.
Andries
On Friday November 24, [email protected] wrote:
> >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
>
> > Now, if you can isolate the relevant part of the diff between
> > 2.95.2 and RH 2.96...
>
> Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
>
> I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and
>
...
>
> So, not all versions of gcc 2.95.2 are equal.
>
> % rpm -qf /usr/bin/gcc
> gcc-2.95.2-51
>
> This is from a SuSE distribution, I forget which, not very recent.
> Revised summary: gcc-2.95.2-51 from SuSE is buggy.
Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same
bug.
Debian applies a total of 49 patches to gcc and the libraries.
I am tempted to write a little script which discards the patches one
by one and re-builds and re-tests each time, and leave it going all
night.... but I'm not sure if I actually will.
NeilBrown
>
> Andries
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Fri, 24 Nov 2000, Neil Brown wrote:
> Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same
> bug.
> Debian applies a total of 49 patches to gcc and the libraries.
>
> I am tempted to write a little script which discards the patches one
> by one and re-builds and re-tests each time, and leave it going all
> night.... but I'm not sure if I actually will.
Not all of them are applied on x86:
% cat stamps/02-patch-stamp-*|less
bootstrap patches applied.
cpp-dos-newlines patches applied.
cpp-macro-doc patches applied.
gcc-cvs-updates-20000220 patches applied.
gcc-default-arch patches applied.
gcc-empty-struct-init patches applied.
gcc-manpage patches applied.
gcc-pointer-arith patches applied.
gcj-debian-policy patches applied.
gcj-vs-iconv patches applied.
gpc-2.95 patches applied.
gpc-updates patches applied.
libg++-update patches applied.
libobjc patches applied.
libstdc++-bastring patches applied.
libstdc++-out-of-mem patches applied.
libstdc++-wall3 patches applied.
libstdc++-wstring patches applied.
reporting patches applied.
And only 4 have any chance to be relevant: gcc-cvs-updates-20000220,
gcc-default-arch, gcc-empty-struct-init. Unfortunately, the first one
is ~100Kb worth of changes. Hmmm... After some cleaning the whole thing
boils down to 11Kb. And I seriously suspect that relevant bits are
in cse.c, loop.c or toplev.c, with the first two being the most likely
candidates (all coming from the -cvs-updates-20000220)...
[email protected] wrote:
<skip>
> % /usr/gcc/aeb/bin/gcc -v
> Reading specs from
> /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
> gcc version 2.95.2 19991024 (release)gcc version 2.95.2 19991024 (release)
> % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
> 0x0
Interesting. On a Slackware 7.1 recently upgraded to glibc 2.2
(and where gcc 2.95.2 from ftp.gnu.org was built because 2.2
requires this version) I get:
% gcc -Wall -O2 -o bug bug.c
% ./bug
0x84800000
% egcs-2.91.66 -Wall -O2 -o bug bug.c
% ./bug
0x0
% gcc -Wall -O -o bug bug.c
% ./bug
0x0
% gcc -v
Reading specs from
/usr/lib/gcc-lib/i386-slackware-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% egcs-2.91.66 -v
Reading specs from
/usr/lib/gcc-lib/i386-slackware-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
Slackware's -current tree was upgraded to glibc 2.2 and gcc
2.95.2, but I built them myself.
--
0@pervalidus.{net, com, dyndns.org}
On Fri, 24 Nov 2000 06:20:33 +0100 (MET), [email protected] wrote:
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
> 0x84800000
> % /usr/gcc/aeb/bin/gcc -v
> Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
> 0x0
>
> So, not all versions of gcc 2.95.2 are equal.
Interesting. Plain vanilla 2.95.2 from ftp.gnu.org exhibits the same
bug on an BSDI2.1 i386 system.
defiant ~/tmp$ gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/i386-pc-bsdi2.1/2.95.2/specs
gcc version 2.95.2 19991024 (release)
defiant ~/tmp$ gcc -O2 -o bug bug.c; ./bug
0x4800000
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Fri, Nov 24, 2000 at 06:20:33AM +0100, [email protected] wrote:
> >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
>
> > Now, if you can isolate the relevant part of the diff between
> > 2.95.2 and RH 2.96...
>
> Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
>
> I just installed gcc 2.95.2 freshly ftp'ed from ftp.gnu.org, and
>
> % /usr/bin/gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
> 0x84800000
> % /usr/gcc/aeb/bin/gcc -v
> Reading specs from /usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
> 0x0
>
> So, not all versions of gcc 2.95.2 are equal.
I believe all 2.95.2's are equal in this, I think the fact that it gives 0
in the nobug case is some other reason:
$ for i in gcc kgcc '/usr/src/gcc-trunk/obj/gcc/xgcc -B /usr/src/gcc-trunk/obj/gcc/' '/usr/src/gcc-2.95.2/obj/gcc/xgcc -B /usr/src/gcc-2.95.2/obj/gcc/'; do $i -v; for j in -mcpu=i386 -mcpu=i586 -mcpu=i686; do $i $j -O2 -o aeb aeb.c; echo -n "$i $j "; ./aeb; done; done
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
gcc -mcpu=i386 0x0
gcc -mcpu=i586 0x0
gcc -mcpu=i686 0x0
Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
kgcc -mcpu=i386 0x0
kgcc -mcpu=i586 0x0
kgcc -mcpu=i686 0x0
Reading specs from /usr/src/gcc-trunk/obj/gcc/specs
Configured with:
gcc version 2.97 20001120 (experimental)
/usr/src/gcc-trunk/obj/gcc/xgcc -B /usr/src/gcc-trunk/obj/gcc/ -mcpu=i386 0x0
/usr/src/gcc-trunk/obj/gcc/xgcc -B /usr/src/gcc-trunk/obj/gcc/ -mcpu=i586 0x0
/usr/src/gcc-trunk/obj/gcc/xgcc -B /usr/src/gcc-trunk/obj/gcc/ -mcpu=i686 0x0
Reading specs from /usr/src/gcc-2.95.2/obj/gcc/specs
gcc version 2.95.2 19991024 (release)
/usr/src/gcc-2.95.2/obj/gcc/xgcc -B /usr/src/gcc-2.95.2/obj/gcc/ -mcpu=i386 0x84800000
/usr/src/gcc-2.95.2/obj/gcc/xgcc -B /usr/src/gcc-2.95.2/obj/gcc/ -mcpu=i586 0x84800000
/usr/src/gcc-2.95.2/obj/gcc/xgcc -B /usr/src/gcc-2.95.2/obj/gcc/ -mcpu=i686 0x0
so the reason why it did not show up in the gcc you picked up from
ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
where the bug does not show up.
Jakub
> > Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
> > gcc version 2.95.2 19991024 (release)
> > % /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
> > 0x84800000
> > % /usr/gcc/aeb/bin/gcc -v
> > Reading specs from
/usr/gcc/aeb/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
> > gcc version 2.95.2 19991024 (release)
> > % /usr/gcc/aeb/bin/gcc -Wall -O2 -o nobug bug.c; ./nobug
> > 0x0
> >
> > So, not all versions of gcc 2.95.2 are equal.
>
> Interesting. Plain vanilla 2.95.2 from ftp.gnu.org exhibits the same
> bug on an BSDI2.1 i386 system.
>
> defiant ~/tmp$ gcc -v
> Reading specs from /usr/local/gnu/lib/gcc-lib/i386-pc-bsdi2.1/2.95.2/specs
> gcc version 2.95.2 19991024 (release)
> defiant ~/tmp$ gcc -O2 -o bug bug.c; ./bug
> 0x4800000
>
> Ion
>
Don't know if anyone else has noticed this but from what I've seen
posted it appears, unless I missed something, the gcc 2.95.2s that have
exibited the bug were compiled for a 386 or a 486 while the one on which it
worked was a 686. Perhaps the bug only appears on certain gcc
configurations. Either the build configuration or the default optimization
method(s), if I remember correctly gcc optimizes for the platform (i.e.
i386, i486, i586, etc) it was configured for by default.
On Fri, 24 Nov 2000, Jakub Jelinek wrote:
>so the reason why it did not show up in the gcc you picked up from
>ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
>where the bug does not show up.
Indeed. I just ran some tests, and I can confirm that gcc 2.95.2 vanilla
exhibits the bug when compiled and run for i486 or i585, but not i686.
/Mikael
> so the reason why it did not show up in the gcc you picked up from
> ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
Yes, you are right.
So 2.95.2 fails for i386, i486, i586 and does not fail for i686.
Andries
[email protected] wrote:
>
> > so the reason why it did not show up in the gcc you picked up from
> > ftp.gnu.org is that you have compiled it so that it defaults to -mcpu=i686
>
> Yes, you are right.
>
> So 2.95.2 fails for i386, i486, i586 and does not fail for i686.
>
RedHat 7.0's gcc 2.96 and kgcc do not seem to exhibit this problem:
me2v@reliant tmp $ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
me2v@reliant tmp $ kgcc -v
Reading specs from
/usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
me2v@reliant tmp $ gcc -O2 -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ gcc -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ kgcc -O2 -o bug bug.c ; ./bug
0x0
me2v@reliant tmp $ kgcc -o bug bug.c ; ./bug
0x0
--
Matthew Vanecek
perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me.
I'm always getting in the way of something...
On Fri, 24 Nov 2000, Neil Brown wrote:
> On Friday November 24, [email protected] wrote:
> > >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> >
> > > Now, if you can isolate the relevant part of the diff between
> > > 2.95.2 and RH 2.96...
> >
> > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
[image from FTP site not buggy]
> > This is from a SuSE distribution, I forget which, not very recent.
> > Revised summary: gcc-2.95.2-51 from SuSE is buggy.
>
> Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the
> same bug. Debian applies a total of 49 patches to gcc and the
> libraries.
The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
(and the ISO images haven't even been available for
one week yet ... *sigh*)
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.conectiva.com/ http://www.surriel.com/
On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
Rik,
We refuse to use it here at present. Builds from it have a lot
of problems, for some reason. Andre is looking into it more
deeply than I, but I agree with your assessment.
Jeff
> On Fri, 24 Nov 2000, Neil Brown wrote:
> > On Friday November 24, [email protected] wrote:
> > > >> ... RedHat's GCC snapshot "2.96" handles this case just fine.
> > >
> > > > Now, if you can isolate the relevant part of the diff between
> > > > 2.95.2 and RH 2.96...
> > >
> > > Maybe I have to be more precise in the statement "gcc 2.95.2 is buggy".
>
> [image from FTP site not buggy]
>
> > > This is from a SuSE distribution, I forget which, not very recent.
> > > Revised summary: gcc-2.95.2-51 from SuSE is buggy.
> >
> > Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the
> > same bug. Debian applies a total of 49 patches to gcc and the
> > libraries.
>
> The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
>
> (and the ISO images haven't even been available for
> one week yet ... *sigh*)
>
> regards,
>
> Rik
> --
> Hollywood goes for world dumbination,
> Trailer at 11.
>
> http://www.conectiva.com/ http://www.surriel.com/
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
> The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
Yes. Probably you have seen it by now, but the difference between
good and bad versions of gcc-2.95.2 did not lie in the applied patches,
but was the difference between compilation for 686 or 386.
It is not your (SuSE's, Debian's) fault. A fix already exists.
Andries
On Sat, 25 Nov 2000, Andries Brouwer wrote:
> On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
>
> > The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
>
> Yes. Probably you have seen it by now, but the difference between
> good and bad versions of gcc-2.95.2 did not lie in the applied patches,
> but was the difference between compilation for 686 or 386.
> It is not your (SuSE's, Debian's) fault. A fix already exists.
Indeed, this should be fixed soon.
I'm sure a simple 'apt-get upgrade' will install a new
gcc RPM on my workstation soon ;)
cheers,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.conectiva.com/ http://www.surriel.com/
Rik van Riel <[email protected]> writes:
> On Sat, 25 Nov 2000, Andries Brouwer wrote:
> > On Sat, Nov 25, 2000 at 03:26:15PM -0200, Rik van Riel wrote:
> >
> > > The gcc-2.95.2-6cl from Conectiva 6.0 is buggy too.
> >
> > Yes. Probably you have seen it by now, but the difference between
> > good and bad versions of gcc-2.95.2 did not lie in the applied patches,
> > but was the difference between compilation for 686 or 386.
> > It is not your (SuSE's, Debian's) fault. A fix already exists.
>
> Indeed, this should be fixed soon.
>
> I'm sure a simple 'apt-get upgrade' will install a new
> gcc RPM on my workstation soon ;)
A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
well. So, if you configure your kernel with `CONFIG_M686=y' the problem
should be gone.
Regards, Olaf.
On 26 Nov 2000, Olaf Dietsche wrote:
> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the
> problem should be gone.
Except for the fact that it'll no longer boot on Pentiums
and 486es ;)
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On Sun, Nov 26, 2000 at 04:33:25PM +0100, Olaf Dietsche wrote:
> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the problem
> should be gone.
Btw, was this ever tested on other arch's? I don't remember seeing
anything come across this list.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[email protected] and be right all the time, or not work at all
http://www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
Mike Castle writes:
> Btw, was this ever tested on other arch's? I don't remember seeing
> anything come across this list.
Well, I've tested it on egcs-1.1.2 and RH's gcc 2.96 on ARM, both of
which appear ok.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
On Sun, 26 Nov 2000 16:33:25 Olaf Dietsche wrote:
>
> A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as
> well. So, if you configure your kernel with `CONFIG_M686=y' the problem
> should be gone.
>
That does not work for 2.2 kernels. Always compile for -m486. To use
the -march flag you need to modify arch/i386/kernel/Makefile. Patch
follows:
================= PATCH patch-gcc-arch:
--- linux-2.2.17/arch/i386/Makefile.orig Wed Nov 22 20:42:49 2000
+++ linux-2.2.17/arch/i386/Makefile Wed Nov 22 20:44:40 2000
@@ -24,23 +24,23 @@
CFLAGS := $(CFLAGS) $(CFLAGS_PIPE) $(CFLAGS_NSR)
ifdef CONFIG_M386
-CFLAGS := $(CFLAGS) -m386 -DCPU=386
+CFLAGS := $(CFLAGS) -march=i386 -DCPU=386
endif
ifdef CONFIG_M486
-CFLAGS := $(CFLAGS) -m486 -DCPU=486
+CFLAGS := $(CFLAGS) -march=i486 -DCPU=486
endif
ifdef CONFIG_M586
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=586
+CFLAGS := $(CFLAGS) -march=i586 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=586
endif
ifdef CONFIG_M586TSC
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=586
+CFLAGS := $(CFLAGS) -march=i586 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=586
endif
ifdef CONFIG_M686
-CFLAGS := $(CFLAGS) -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
-DCPU=686
+CFLAGS := $(CFLAGS) -march=i686 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=686
endif
HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[email protected] #> more beer
Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown
Hello all,
I have used patch from GCC-PATCHES list
posted by Bernd Schmidt <bernds at redhat dot com>.
Because of high importance I am forwarding this patch to
Linux-Kernel. Patch seems to solve problem.
I have added warning print for case of problem,
to find which parts of Linux kernel could be affected by this GCC
bug. There are results:
linux-2.4.0-test10-pre? compiled for K7
make[2]: Entering directory `/usr/src/linux-2.4.0-t9/fs'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing -c -o block_dev.o block_dev.c
block_dev.c: In function `block_read':
block_dev.c:311: warning: possible original gcc 2.95.2 error c/877
make[2]: Entering directory `/usr/src/linux-2.4.0-t9/ipc'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing -c -o msg.o msg.c
msg.c: In function `sys_msgctl':
msg.c:576: warning: possible original gcc 2.95.2 error c/877
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-t9/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4 -fno-strict-aliasing -c -o sem.o sem.c
I have run same compilation for 2.2.15 kernel compiled for K6
make[2]: Entering directory `/usr/src/linux-2.2.15/fs'
block_dev.c: In function `block_read':
block_dev.c:304: warning: possible original gcc 2.95.2 error c/877
I hope that my mail is not only waste of your time.
These possible wrong compiled files could be sources of other
false kernel related bugs.
If you have interest I will to try to compile 2.2.x and 2.4.0-x kernels
for bare i586 to find more such problematic places.
Best wishes
Pavel Pisa
PS: For faster response CC any reply directly to my address, please.
-----------------------------------------------------------------------------
To: aeb at cwi dot nl
Subject: Re: c/877: gcc 2.95.2 generates incorrect code on i386
From: Bernd Schmidt <bernds at redhat dot com>
Date: Fri, 24 Nov 2000 15:40:05 +0000 (GMT)
cc: gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot
org
On 24 Nov 2000 [email protected] wrote:
> >Synopsis: gcc 2.95.2 generates incorrect code on i386
> It seems that a variable length shift of a long long
> is miscompiled. This causes Linux kernel bugs.
This is (as usual) a bug in reload. We have two insns:
(insn 69 67 70 (set (reg:QI 46)
(subreg:QI (reg:SI 43) 0))
(insn 70 69 72 (set (reg:DI 44)
(ashiftrt:DI (reg:DI 44)
(reg:QI 46))) (expr_list:REG_DEAD 46)
Neither reg 46 nor reg 44 gets a hard register. While processing insn 70,
reload decides that it will need reg 2 (%cl) for reg 46, and reg 3/4
(%ebx/%esi) for reg 44. It also notices that the value of reg 44 is
already available in reg 1/2 (%edx/%ecx), so it can avoid loading it from
the stack and instead use reg 1/2 as overriding input. It then notices
that reg 46 dies in insn 70 and is set in insn 69, so it would be possible
simply to replace the destination of insn 69 with the reload reg (%cl).
The problem is that by changing insn 69 to store into %cl, the input
override for the other reload gets clobbered. Oops. The function
reload_reg_free_for_value_p doesn't test for this case.
I'm currently bootstrapping with the patch below; I'll check it in (along
with a testcase) once that finishes. It won't apply cleanly to 2.95, but
it should be quite easy to figure out how to apply it. This is an obvious
candidate should we decide to make a 2.95.3 release.
(As a side note, this bug has nothing to do with the fact that there's a
long long shift in this testcase, although I think I've noticed a bunch
of potential bugs related to multiword values in the reload inheritance
code while looking at this testcase...)
Bernd
* reload1.c (conflicts_with_override): New function.
(emit_input_reload_insns): Use it to tighten test for validity
of substituting into output of previous insn.
Index: reload1.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/reload1.c,v
retrieving revision 1.241
diff -u -p -r1.241 reload1.c
--- reload1.c 2000/11/14 10:23:37 1.241
+++ reload1.c 2000/11/24 15:11:43
@@ -417,6 +417,7 @@ static int reload_reg_reaches_end_p PARA
enum reload_type));
static int allocate_reload_reg PARAMS ((struct insn_chain *, int,
int));
+static int conflicts_with_override PARAMS ((rtx));
static void failed_reload PARAMS ((rtx, int));
static int set_reload_reg PARAMS ((int, int));
static void choose_reload_regs_init PARAMS ((struct insn_chain *, rtx *));
@@ -4882,6 +4883,21 @@ reload_reg_free_for_value_p (regno, opnu
return 1;
}
+/* Determine whether the reload reg X overlaps any rtx'es used for
+ overriding inheritance. Return nonzero if so. */
+
+static int
+conflicts_with_override (x)
+ rtx x;
+{
+ int i;
+ for (i = 0; i < n_reloads; i++)
+ if (reload_override_in[i]
+ && reg_overlap_mentioned_p (x, reload_override_in[i]))
+ return 1;
+ return 0;
+}
+
/* Give an error message saying we failed to find a reload for INSN,
and clear out reload R. */
static void
@@ -6215,6 +6231,7 @@ emit_input_reload_insns (chain, rl, old,
&& dead_or_set_p (insn, old)
/* This is unsafe if some other reload
uses the same reg first. */
+ && ! conflicts_with_override (reloadreg)
&& reload_reg_free_for_value_p (REGNO (reloadreg),
rl->opnum,
rl->when_needed,