gcc-2.95.2-51 is buggy

gcc-2.95.2-51 is buggy

[Andries.Brouwer]

>> ... 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Neil Brown]

On Friday November 24, Andries.Brouwer@cwi.nl 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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Alexander Viro]

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)...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Rik van Riel]

On Fri, 24 Nov 2000, Neil Brown wrote:
> On Friday November 24, Andries.Brouwer@cwi.nl 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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Jeff V. Merkey]

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, Andries.Brouwer@cwi.nl 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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Andries Brouwer]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Rik van Riel]

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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Olaf Dietsche]

Rik van Riel <riel@conectiva.com.br> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Rik van Riel]

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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Mike Castle]

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
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Russell King]

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        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[J . A . Magallon]

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:jamagallon@able.es                                     #> more beer

Linux 2.2.18-pre23-vm #3 SMP Wed Nov 22 22:33:53 CET 2000 i686 unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Ion Badulescu]

On Fri, 24 Nov 2000 06:20:33 +0100 (MET), Andries.Brouwer@cwi.nl 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Linux Kernel Developer]

> > 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Jakub Jelinek]

On Fri, Nov 24, 2000 at 06:20:33AM +0100, Andries.Brouwer@cwi.nl 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Frédéric L . W . Meunier]

Andries.Brouwer@cwi.nl 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}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Andries.Brouwer]

> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Matthew Vanecek]

Andries.Brouwer@cwi.nl 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...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Mikael Pettersson]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gcc-2.95.2-51 is buggy

[Pavel Pisa;research student]

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 aeb@cwi.nl 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,




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/