ct@dde.dk (Claus Tondering) (09/27/89)
Consider the following program:
main()
{
int p=3, *q=&p;
*q=4;
printf("%d\n",p);
}
Is it acceptable that this program prints 3 instead of 4? The variable
p is not declared volatile, and therefore the fact that *q=4 assigns
4 to p may be considered a side effect.
--
Claus Tondering
Dansk Data Elektronik A/S, Herlev, Denmark
E-mail: ct@dde.dk or ...!uunet!mcvax!dkuug!dde!ctgwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)
In article <712@Aragorn.dde.dk> ct@dde.dk (Claus Tondering) writes:
- int p=3, *q=&p;
- *q=4;
- printf("%d\n",p);
-Is it acceptable that this program prints 3 instead of 4? The variable
-p is not declared volatile, and therefore the fact that *q=4 assigns
-4 to p may be considered a side effect.
No, a correct implementation must print "4" (and a new-line).
You're confusing "volatile" with "noalias" (which is no longer
in the proposed standard). C supports aliasing via pointers.barmar@kulla (Barry Margolin) (09/28/89)
In article <712@Aragorn.dde.dk> ct@dde.dk (Claus Tondering) writes: > int p=3, *q=&p; > *q=4; > printf("%d\n",p); >Is it acceptable that this program prints 3 instead of 4? The variable >p is not declared volatile, and therefore the fact that *q=4 assigns >4 to p may be considered a side effect. No, the program must print 4. Since p's address is taken, the optimizer should know that it isn't safe to assume that only assignments to p will modify its value. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
afscian@violet.waterloo.edu (Anthony Scian) (09/29/89)
In article <712@Aragorn.dde.dk> ct@dde.dk (Claus Tondering) writes: >Consider the following program: > > main() > { > int p=3, *q=&p; > > *q=4; > printf("%d\n",p); > } > >Is it acceptable that this program prints 3 instead of 4? NO. This is a convenient type of oversight that allows so called "optimizing compilers" like Turbo C and Microsoft C to squeeze out extra performance from benchmarks. Too bad if production code doesn't run with the optimizer turned on. True optimizing compilers (WATCOM C,GNU CC) don't resort to "tricks" like this. -- Anthony //// Anthony Scian afscian@violet.uwaterloo.ca afscian@violet.waterloo.edu //// "I can't believe the news today, I can't close my eyes and make it go away" -U2
scott@bbxsda.UUCP (Scott Amspoker) (09/29/89)
In article <30292@news.Think.COM> barmar@kulla (Barry Margolin) writes: >In article <712@Aragorn.dde.dk> ct@dde.dk (Claus Tondering) writes: >> int p=3, *q=&p; >> *q=4; >> printf("%d\n",p); >>Is it acceptable that this program prints 3 instead of 4? The variable >>p is not declared volatile, and therefore the fact that *q=4 assigns >>4 to p may be considered a side effect. > >No, the program must print 4. Since p's address is taken, the >optimizer should know that it isn't safe to assume that only >assignments to p will modify its value. I noticed that the suject line refers to "volatile". The code example does not present a situation for the volatile keyword. The problem presented in the code example is deals with an optimizer headache known an "aliasing". Some compilers provide a "don't-check-aliasing" option that may generate somewhat faster code but could also generate incorrect code. The volatile keyword is used when dealing with data that could be modified by an interrupt or signal handler. Consider the following loop waiting for a flag indicating that some external event occurred. It is assumed that the interrupt/signal handler will set the flag: while (!flag) ; /* loop until flag set */ The optimizer notices that flag is never changed in the loop and may do some strange things. The value for flag may be loaded into a register avoiding further access to the actual memory location of flag. Declaring flag as "volatile" tells the compiler that someone else is also using that memory location and that the value could "magically" change at any time. There is no way a data flow analyser could determine that. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232
Don_A_Corbitt@cup.portal.com (10/02/89)
In article <???> Anthony Scian afscian@violet.uwaterloo.ca wrote [rest of article deleted] >>Is it acceptable that this program prints 3 instead of 4? >NO. This is a convenient type of oversight that allows so called >"optimizing compilers" like Turbo C and Microsoft C to squeeze >out extra performance from benchmarks. Too bad if production code >doesn't run with the optimizer turned on. True optimizing >compilers (WATCOM C,GNU CC) don't resort to "tricks" like this. >-- >Anthony >//// Anthony Scian afscian@violet.uwaterloo.ca afscian@violet.waterloo.edu /// / I have heard that MSC 5.0 had optimizer problems, and most are fixed in 5.1. Of more importance, Turbo C doesn't have an 'aggressive' optimizer, and is not guilty of the sin mentioned here. It generates fairly good code anyway. Don_A_Corbitt@cup.portal.com Not a spokesperson for CrystalGraphics, Inc. "Mail flames, post apologies" "Support the three-line signature" Contrary to popular belief
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/02/89)
In article <16785@watdragon.waterloo.edu>, afscian@violet.waterloo.edu (Anthony Scian) writes: | In article <712@Aragorn.dde.dk> ct@dde.dk (Claus Tondering) writes: | >Consider the following program: | > | > main() | > { | > int p=3, *q=&p; | > | > *q=4; | > printf("%d\n",p); | > } | > | >Is it acceptable that this program prints 3 instead of 4? | | NO. This is a convenient type of oversight that allows so called | "optimizing compilers" like Turbo C and Microsoft C to squeeze | out extra performance from benchmarks. Too bad if production code | doesn't run with the optimizer turned on. True optimizing | compilers (WATCOM C,GNU CC) don't resort to "tricks" like this. You are correct that 3 is not acceptable, but what in the world has the original topic to do with the attack on MSC and TC? I don't know about TC, but I tried MSC on the program as posted and it doesn't have any such problem. I do not have easy access to old versions of MSC or TC, so I can speak only to the receent (4.85, 5.0, 5.1) MSC. Those version correctly print 4. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/03/89)
In article <16785@watdragon.waterloo.edu>, afscian@violet.waterloo.edu (Anthony Scian) writes: | NO. This is a convenient type of oversight that allows so called | "optimizing compilers" like Turbo C and Microsoft C to squeeze | out extra performance from benchmarks. I wrote a reply saying that MSC v4.85 and later didn't do this. Someone replied that if certainly did, if you use the -Oa option. For the record, that's true. If you use -Oa to tell the compiler to ignore aliasing it will. If you use -Ox (perform unsafe optimizations) it will do funny things in complex code. And if you use -M2 (generate 286 code) it won't run on your XT. Having the compiler do just what you requested doesn't seem like an error to me. X3J11 recognized the need to tell compilers in general what is safe when they added volatile (and the brief moments when noalias existed). When a user selects a option which tells the compiler to ignore possible problems s/he certainly shouldn't be surprized if the problems come up. If this happened with the standard -O option I would agree that a bug was present. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
dts@quad.uucp (David T. Sandberg) (10/04/89)
In article <756@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: :In article <16785@watdragon.waterloo.edu>, afscian@violet.waterloo.edu (Anthony Scian) writes: :| NO. This is a convenient type of oversight that allows so called :| "optimizing compilers" like Turbo C and Microsoft C to squeeze :| out extra performance from benchmarks. : : I wrote a reply saying that MSC v4.85 and later didn't do this. :Someone replied that if certainly did, if you use the -Oa option. For the record, MSC 5.1 produces the correct results from the original program snippet (4) even when compiling with either the -Oa or the -Ox switch. -- David Sandberg - Quadric Systems "I began neglecting my shoes." PSEUDO: dts@quad.uucp ACTUAL: ..uunet!rosevax!sialis!quad!dts