tan_j@wums2.wustl.edu (07/18/90)
>> item 1985 >> Is it a bug or not? I can compile the piece of program below successfully >> on Sun 3/60(4.0_Export), HP900/825(7.00). But I failed to do that on 4D 20 >> under IRIX 3.2. struct Alist_Entry { void *slot; } ; main() { register struct Alist_Entry *ap; *( (int *) (ap->slot) ) = 11; *((char *)(ap->slot)) = 'a'; } ======================================================================= If you read the SGI C Language reference manual on operator conversions (section 4.7 on Version 1.0 manual), it reads: The (nonexistent) value of a object may not be used in any way, and neither explicit nor implicit conversion may be applied. ...... etc.... and section 3.2 on Type, The void type specifies an empty set of values. It is used as the type returned by functions that generate no value. Which means SGI C compiler does not allow void type usage as on other systems. ======================================================================= You may want to check your C code also. This is a common mistake. Suppose void type is accepted on SGI, *( (int *) (ap->slot) ) = 11 will type cast ap->slot into an integer pointer, then change the content that is pointed by ap->slot to 11, not the ap->slot. So where is your initialization of ap->slot ? It is NULL !! Declaring a pointer does not allocate a 'real' (you know what I mean) space. What you want probably is declare another variable, NOT pointer, register struct Alist_Entry *ap, temp; ap=&temp; Then it will be fine. "SGI newcomer" tan_j@wums.stl.edu Washington University Medical School
tan_j@wums2.wustl.edu (07/18/90)
Alright, this is actually in addition to my comments about the C code.
I was saying that it is easily it is easy to forget the initialization
of pointer, and I prove it myself. I forgot to indicate that the
ap->slot itself must be initialized. Therefore, add something like,
int a;
ap->slot = (void *)&a;
somewhere along the line is a must.
Another flaw that I did not see is
the register declaration. register storage class only takes word size
variable. So, the declaration
register struct anystruct *pointer_variable;
is OK because pointer is essentially a word-size variable. But
register struct anystruct plain_variable;
is a piece of bad code ! If anystruct is declared as
struct anystruct {
int a;
char b[50];
void *c;
};
Then it is obvious that a register cannot hold all variables declared in
the structure. Although in your case, you declared a struct with only
a void pointer member. I don't really know the answer. I guess it
depends on the compiler ? Comments welcome.
"Never do it on early morning"
tan_j@wums.wustl.eduguy@auspex.auspex.com (Guy Harris) (07/22/90)
>Which means SGI C compiler does not allow void type usage as on other >systems. *No* system should let you refer to the non-existent "value" of a "void" object. *Any* system that supports "void *" should, however, let you cast a "void *" to another pointer type. The program in question is doing the latter, not the former. As was noted in another posting, there's a bug in the 3.2 C compiler that causes it not to handle "void *" - I'll bet it was the same bug that got fixed at Sun for SunOS 4.0; it probably is the same bug if the front end of the SGI/MIPS C compiler is PCC-based (basically, the internal code that represents "void *" was originally also the code used for an internal "no type" indication - "void *" wasn't officially in C, but PCC didn't detect it or prohibit it; the change is to use a different code for the "no type" indication).
mcfong@mercury.sybase.com (11/01/90)
When the following program is run:
main()
{
printf("7e-7 = %f\n", 7e-7);
}
I get the following results on the following MIPS-based systems:
RISC ULTRIX 3.0 7e-7 = 0.000000
SGI IRIX 3.2 7e-7 = 0.000000
MIPS OS 1.0 7e-7 = 0.000001
Looks like yet another compiler bug which MIPS has fixed but DEC and
SGI have not yet picked up.
Would someone please run the same program on the latest version of RISC
ULTRIX (4.0) and SGI IRIX (3.3) and see if DEC or SGI have fixed the
problem in their later releases?
Thanks.
Martin C. Fong
Sybase Inc.
6475 Christie Ave.
Emeryville, CA 94607
(415)596-3822
sun!sybase!mcfong
mcfong@sybase.com
decwrl::"@tis.llnl.gov:mcfong@sybase.com"langley@ds1.scri.fsu.edu (Randolph Langley) (11/01/90)
Martin Fong writes: >I get the following results on the following MIPS-based systems: > > RISC ULTRIX 3.0 7e-7 = 0.000000 > SGI IRIX 3.2 7e-7 = 0.000000 > MIPS OS 1.0 7e-7 = 0.000001 > >Looks like yet another compiler bug which MIPS has fixed but DEC and >SGI have not yet picked up. > >Would someone please run the same program on the latest version of RISC >ULTRIX (4.0) and SGI IRIX (3.3) and see if DEC or SGI have fixed the >problem in their later releases? I just checked IRIX 3.3.1, and the almost most recent patch[*] for ULTRIX 4.0 and they both yield the same thing as previously. rdl [*] I got ANOTHER one yesterday from DEC - wish they would release when the code was little more steady, instead of these unending patches. I refuse to yield to the temptation of making a smart remark about users providing what little QC that DEC seems to be doing.
brian@cimage.com (Brian Kelley) (11/01/90)
In article <11565@sybase.sybase.com> mcfong@mercury.sybase.com () writes: >I get the following results on the following MIPS-based systems: > > RISC ULTRIX 3.0 7e-7 = 0.000000 > SGI IRIX 3.2 7e-7 = 0.000000 > MIPS OS 1.0 7e-7 = 0.000001 > >Looks like yet another compiler bug which MIPS has fixed but DEC and >SGI have not yet picked up. > >Would someone please run the same program on the latest version of RISC >ULTRIX (4.0) and SGI IRIX (3.3) and see if DEC or SGI have fixed the >problem in their later releases? I just ran it under 4.0, and sure enough: RISC ULTRIX 4.0 7e-7 = 0.000000 I think the main problem is ULTRIX 4.0 is using version 2.00 of the MIPS C compiler. Version 2.10 probably fixes this bug (I know it fixes several others). We are in the process of trying to get 2.10 from DEC. It isn't clear which version 4.1 will ship with. --- brian@cimage.com
meggers@mothra.nts.uci.edu (Mark Eggers) (11/02/90)
No change in Ultrix 4.0 for the generic cc compiler. /mde/
steven@uicadd.csl.uiuc.edu (Steven Parkes) (11/02/90)
In article <1990Nov1.153433.4006@cimage.com>, brian@cimage.com (Brian Kelley) writes: |> I just ran it under 4.0, and sure enough: |> RISC ULTRIX 4.0 7e-7 = 0.000000 |> I think the main problem is ULTRIX 4.0 is using version 2.00 of the MIPS |> C compiler. Version 2.10 probably fixes this bug (I know it fixes several |> others). We are in the process of trying to get 2.10 from DEC. It isn't |> clear which version 4.1 will ship with. cc2.1 comes with the f77 layered product ... and it gives the same result as cc2.0. steven parkes --------------------------------------- University of Illinois Coordinated Science Laboratory steven@pacific.csl.uiuc.edu -------------------------
meissner@osf.org (Michael Meissner) (11/02/90)
In article <11565@sybase.sybase.com> mcfong@mercury.sybase.com writes: | When the following program is run: | | main() | { | printf("7e-7 = %f\n", 7e-7); | } | | I get the following results on the following MIPS-based systems: | | RISC ULTRIX 3.0 7e-7 = 0.000000 | SGI IRIX 3.2 7e-7 = 0.000000 | MIPS OS 1.0 7e-7 = 0.000001 | | Looks like yet another compiler bug which MIPS has fixed but DEC and | SGI have not yet picked up. | | Would someone please run the same program on the latest version of RISC | ULTRIX (4.0) and SGI IRIX (3.3) and see if DEC or SGI have fixed the | problem in their later releases? I did some checking (doesn't anybody look at the machine code these days), and it's not a compiler bug, but a library bug. You can demonstrate it by changing the program to: main() { printf ("7e-7 = %g\n", 7e-7); } and it will print "7e-7 = 7e-07" on my Ultrix 3.1 system. On OSF/1, it prints the correct answer. I used by the standard C compiler (on Ultrix) and GCC (on Ultrix and OSF/1), and they give identical results. I suspect the bug is that the library does not round %f entries, but truncates them instead. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
DDAVID@F.ADELAIDE.EDU.AU (11/06/90)
Martin Fong writes: >I get the following results on the following MIPS-based systems: > > RISC ULTRIX 3.0 7e-7 = 0.000000 > SGI IRIX 3.2 7e-7 = 0.000000 > MIPS OS 1.0 7e-7 = 0.000001 > >Looks like yet another compiler bug which MIPS has fixed but DEC and >SGI have not yet picked up. > This is another example of the following: This test program main() { float x; while (1) { printf("input x : "); scanf("%f", &x); printf("x = %f -> %.0f\n", x,x); } } produces the following output (Irix 3.3.1) : x = 0.2 -> 0 x = 0.6 -> 0 ?? x = 0.95 -> 0 ?? x = 0.99 -> 1 ???? x = 1.2 -> 1 x = 1.6 -> 2 x = 2.2 -> 2 x = 2.6 -> 3 x = -1.6 -> -2 x = -1.20 -> -1 x = -0.99 -> -1 ???? x = -0.90 -> 0 ?? x = -0.60 -> 0 ?? x = -0.2 -> 0 so you can see that printf is not consistent in rounding to the nearest number for floating point numbers between -1 and 1. A minor bug but annoying. I hope it is fixed in the next release. Regards, David Netherway, Australian Cranio-Facial Unit