[comp.sys.dec] Compiler Bug

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