davids@bduxpe (Peter Davids) (07/26/90)
Some days (or weeks) ago, there was a posting in comp.sys.dec or
comp.unix.ultrix that described a compiler bug in Ultrix CC.
We have DEC 3100 Workstation with Ultrix 3.1 and UWS 2.1 running.
The following little (and correct!?) C-program gives different results,
depending on the optimizer options.
The programm look a bit like the own posted some time ago...
====cut here==============================
char * malloc();
main()
{
char * ba;
int i=3;
printf("%d\n", i*(-6) );
ba = malloc (100);
printf("%d\n", i*(-6) );
}
/*
* Results:
*
* Compile with: 'cc b.c' default
*
* -18
* 18
*
*
*
* Compile with: 'cc -O b.c' optimize
*
* -18
* -18
*
*
*
* Compile with: 'cc -O0 b.c' don't optimize
*
* 18
* 18
*
*
*/
=====================================================================
Questions
o Does anybody know the reasons for this behaviour
o Are results the same unter Ultrix 3.0 or 4.0
(we only have 3.1)
o Is there any solution around that problem.
I will be happy about any idea or answer (other bugs would be also
very interesting)
--
_________________________________________________________________________
Peter Davids Lehrstuhl fuer Informatik IV RWTH Aachen D-5100 Aachen
Tel. +241-804522 Fax: +241-806295 davids@informatik.rwth-aachen.de
jg@crl.dec.com (Jim Gettys) (07/26/90)
Sounds like a bug under 3.1....
Results under 4.0 (which has a new compiler suite...)
cat >foo.c
char * malloc();
main()
{
char * ba;
int i=3;
printf("%d\n", i*(-6) );
ba = malloc (100);
printf("%d\n", i*(-6) );
}
zorch % cc -O foo.c -o foo
zorch % foo
-18
-18
zorch % cc foo.c -o foo
zorch % foo
-18
-18
zorch % cc -O0 foo.c -o foo
zorch % foo
-18
-18
zorch % cc -O3 foo.c -o foo
zorch % foo
-18
-18
zorch % cc -O4 foo.c -o foo
zorch % foo
-18
-18
zorch % cc -O1 foo.c -o foo
zorch % foo
-18
-18
zorch %
shodsdon@elrond.CalComp.COM (Steve V. Hodsdon) (07/27/90)
In article <3152@rwthinf.UUCP>, davids@bduxpe (Peter Davids) writes: > > We have DEC 3100 Workstation with Ultrix 3.1 and UWS 2.1 running. > The following little (and correct!?) C-program gives different results, > depending on the optimizer options. > The programm look a bit like the own posted some time ago... > > > ====cut here============================== > char * malloc(); > > main() > { > char * ba; > int i=3; > printf("%d\n", i*(-6) ); > ba = malloc (100); > printf("%d\n", i*(-6) ); > } > > I will be happy about any idea or answer (other bugs would be also > very interesting) I am running a MIPS box with the R2600 CPU card (R2000 processor). Here is the output: (using uMIPS 2.0) [shodsdon@(bifur)/u/shodsdon/src] 3 %cc b.c [shodsdon@(bifur)/u/shodsdon/src] 4 %a.out -18 18 [shodsdon@(bifur)/u/shodsdon/src] 5 %cc -O b.c [shodsdon@(bifur)/u/shodsdon/src] 6 %a.out -18 -18 [shodsdon@(bifur)/u/shodsdon/src] 7 %cc -O0 b.c [shodsdon@(bifur)/u/shodsdon/src] 8 %a.out 18 18 Kinda makes you wonder. > _________________________________________________________________________ > Peter Davids Lehrstuhl fuer Informatik IV RWTH Aachen D-5100 Aachen > Tel. +241-804522 Fax: +241-806295 davids@informatik.rwth-aachen.de -- Steve Hodsdon | Stay sane inside insanity. shodsdon@elrond.CalComp.COM | Don't dream it - Be it. {decvax|harvard}!elrond!shodsdon | (603) 885-8324 |
hudgens@sun13.scri.fsu.edu (Jim Hudgens) (07/30/90)
How about this one.
Under Ultrix 4.0, we get this behavior:
$ cat bug.c
#include<stdio.h>
main()
{
int d;
double f;
long l;
int i;
i = 4;
f = 244.0;
l = 2000;
d = l * i/f;
printf("%d * %d / %f = %d\n",
l, i, f, d);
}
$ cc bug.c
$ a.out
2000 * 4 / 244.000000 = 32
$ cc -O3 bug.c
$ a.out
Segmentation fault
It seems to be crashing in the printf. Nothing obvious in the
assembly listing. Yet under Ultrix 3.1d, we get:
$ cc bug.c
$ a.out
2000 * 4 / 244.000000 = 32
$ cc -O3 bug.c
$ a.out
2000 * 4 / 244.000000 = 32
$
This code is condensed from a fairly large program and was found by
a scientist here.
---
Disclaimer: I didn't do it.
Jim Hudgens Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu
--
---
Disclaimer: I didn't do it.
Jim Hudgens Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu
grunwald@foobar.colorado.edu (Dirk Grunwald) (07/30/90)
>>>>> On 30 Jul 90 14:20:37 GMT, hudgens@sun13.scri.fsu.edu (Jim Hudgens) said:
JH> How about this one.
JH> Under Ultrix 4.0, we get this behavior:
JH> $ cat bug.c
JH> #include<stdio.h>
JH> main()
JH> {
JH> int d;
JH> double f;
JH> long l;
JH> int i;
JH> i = 4;
JH> f = 244.0;
JH> l = 2000;
JH> d = l * i/f;
JH> printf("%d * %d / %f = %d\n",
JH> l, i, f, d);
JH> }
--
this is program 'testb' in the following. Program 'testa' is the
previous one involving 'malloc'.
Using 'gcc' as done by meissner@osf.org, the following results. You
can pick up the tar file for building this (heavily modified) version
of 'gcc' from foobar.colorado.edu:pub/Gnu-For-Pmax. Be warned that
that 'gcc' -O3 and -O2 optimization produces code about 10-20% slower
than Mips 'cc' (1.31). I do not know how it compares to the mips 2.x
suite.
[foobar-81] gcc -o testa testa.c
[foobar-82] ./testa
-18
-18
[foobar-83] gcc -O -o testa testa.c
[foobar-84] ./testa
-18
-18
[foobar-85] gcc -o testa -O2 testa.c
[foobar-86] ./testa
-18
-18
[foobar-87] gcc -o testb testb.c
[foobar-88] ./testb
2000 * 4 / 244.000000 = 32
[foobar-89] gcc -o testb -O testb.c
[foobar-90] ./testb
2000 * 4 / 244.000000 = 32
[foobar-91] gcc -o testb -O2 testb.c
[foobar-92] ./testb
2000 * 4 / 244.000000 = 32
[foobar-93]
hoyt@laura.alf.dec.com (Kurt Hoyt) (07/30/90)
In article <327@sun13.scri.fsu.edu>, hudgens@sun13.scri.fsu.edu (Jim Hudgens) writes: > Under Ultrix 4.0, we get this behavior: [program deleted] > $ cc bug.c > $ a.out > 2000 * 4 / 244.000000 = 32 > $ cc -O3 bug.c > $ a.out > Segmentation fault > > It seems to be crashing in the printf. Nothing obvious in the > assembly listing. Yet under Ultrix 3.1d, we get: [it works] I'm running ULTRIX 4.0, and I get: % cc bug.c % a.out 2000 * 4 / 244.000000 = 32 % cc -O3 bug.c % a.out 2000 * 4 / 244.000000 = 32 Which 4.0 (mine says rev 174)? Which cc version? Which CPU type? % ls -l /usr/bin/cc lrwxrwxrwx 1 root 13 May 24 17:41 /usr/bin/cc@ -> cc2.0 ..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:..:.. Kurt in Atlanta "More than 4 billion chickens in America hoyt@decatl.alf.dec.com each year do not have a single happy moment hoyt@laura.alf.dec.com in their lives." -- PETA News
hudgens@sun13.scri.fsu.edu (Jim Hudgens) (07/31/90)
In article <1990Jul30.165432.9590@decatl.dec.com> hoyt@laura.alf.dec.com (Kurt Hoyt) writes: >In article <327@sun13.scri.fsu.edu>, hudgens@sun13.scri.fsu.edu (Jim Hudgens) writes: >> Under Ultrix 4.0, we get this behavior: > >[program deleted] > >I'm running ULTRIX 4.0, and I get: > > [[ dang, it works for him ]] > >Which 4.0 (mine says rev 174)? Which cc version? Which CPU type? > Hmmm. We're running 4.0, rev 174. Same cc version as yourself (cc2.0). R5000 CPU. I think it was a pretty straightforward installation. I tried it on 3 machines up here (all R5000's), and got exactly the same results. Perhaps we've messed up one of the libraries. Anyone else get these results? Apologies in advance if this turns out to be a local problem... -- --- Disclaimer: I didn't do it. Jim Hudgens Supercomputer Computations Research Institute hudgens@sun13.scri.fsu.edu
iglesias@orion.oac.uci.edu (Mike Iglesias) (07/31/90)
In article <329@sun13.scri.fsu.edu> hudgens@sun13.scri.fsu.edu (Jim Hudgens) writes: > [stuff deleted] >Hmmm. We're running 4.0, rev 174. Same cc version as yourself >(cc2.0). R5000 CPU. I think it was a pretty straightforward >installation. I tried it on 3 machines up here (all R5000's), >and got exactly the same results. Perhaps we've messed up one of >the libraries. Anyone else get these results? Your program works fine on our DECstation 5000/200 running Ultrix 4.0 (rev 163), UWS 4.0 (rev 164), cc 2.0. We just installed 4.0 on this DECstation from the release tapes. Mike Iglesias University of California, Irvine Internet: iglesias@orion.oac.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
jg@crl.dec.com (Jim Gettys) (07/31/90)
Very strange. On my 4.0 system (almost, anyway; we don't have the final patches installed) I get: zorch % cc bug.c zorch % a.out 2000 * 4 / 244.000000 = 32 zorch % cc -O2 bug.c zorch % a.out 2000 * 4 / 244.000000 = 32 zorch % cc -O3 bug.c zorch % a.out 2000 * 4 / 244.000000 = 32 zorch % cc -O4 bug.c zorch % a.out 2000 * 4 / 244.000000 = 32 Are you sure you did your tests on the systems you thought you did? - Jim
hudgens@sun13.scri.fsu.edu (Jim Hudgens) (08/01/90)
In article <1990Jul31.133726.23555@crl.dec.com> you write: >Very strange. On my 4.0 system (almost, anyway; we don't >have the final patches installed) I get: > [[[ it works ]]] >Are you sure you did your tests on the systems you thought >you did? > - Jim My fault entirely. Not a bug at all. We had installed the 3.1 fortran compiler on a 4.0 machine as a stopgap measure until our Fortran 4.0 CD arrived; from the looks of it, we were lucky to have it work as well as it did. I hadn't considered that the two compilers were so interdependent... Uninstalling fortran and reinstalling from CD seems to have fixed this problem (and probably others, as well). My apologies.... Jim Hudgens Disclaimer: I didn't do it. Jim Hudgens Supercomputer Computations Research Institute hudgens@sun13.scri.fsu.edu -- Disclaimer: I didn't do it. Jim Hudgens Supercomputer Computations Research Institute hudgens@sun13.scri.fsu.edu