* Unreferenced lock variables @ 1999-04-11 0:00 Simon Wright 1999-04-11 0:00 ` Tom Moran 1999-04-12 0:00 ` Robert Dewar 0 siblings, 2 replies; 24+ messages in thread From: Simon Wright @ 1999-04-11 0:00 UTC (permalink / raw) I've been looking at using a 'control by allocation' technique (I'm sure there's a more standard name, but I can't find it at the moment: a resource is encapsulated in a type such that declaring an object of the type allocates the resource). For example, procedure Mark (R : in out Synchronized_Unbounded_Ring) is Lock : BC.Support.Synchronization.Write_Lock (R.The_Monitor); begin Mark (Unbounded_Ring (R)); end Mark; where the initialization of Lock calls the appropriate operations on R.The_Monitor (which is a class-wide access ..) to ensure exclusion, in this case for a Writer. Now, GNAT quite properly warns me that Lock is unused; so, having been bitten this way once, I cast around and found that inserting pragma Volatile (Lock); will eliminate the warning. However, it doesn't seem to be as legitimate a use as in the recent thread on Handling Addressing Errors; is there a better way? pragma Import (Ada, Lock) perhaps? or should I look for a different style? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-11 0:00 Unreferenced lock variables Simon Wright @ 1999-04-11 0:00 ` Tom Moran 1999-04-12 0:00 ` Robert Dewar 1 sibling, 0 replies; 24+ messages in thread From: Tom Moran @ 1999-04-11 0:00 UTC (permalink / raw) >Now, GNAT quite properly warns me that Lock is unused There are also other perfectly legal cases where GNAT warns you about something that doesn't need a warning. > pragma Volatile (Lock); >will eliminate the warning. I myself wouldn't clutter good Ada code with spurious and misleading things like this just to turn off overly conservative compiler warnings. If you can do that in an inocuous way, great, but this particular one is likely to confuse some poor maintainer down the road., ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-11 0:00 Unreferenced lock variables Simon Wright 1999-04-11 0:00 ` Tom Moran @ 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright 1 sibling, 1 reply; 24+ messages in thread From: Robert Dewar @ 1999-04-12 0:00 UTC (permalink / raw) In article <x7v4smnszvu.fsf@pogner.moho>, Simon Wright <simon@pogner.demon.co.uk> wrote: > is there a better way [of avoiding the warning] why not pragma Warnings (Off, Lock); -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Robert Dewar @ 1999-04-12 0:00 ` Simon Wright 1999-04-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Simon Wright @ 1999-04-12 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-dejanews.com> writes: > In article <x7v4smnszvu.fsf@pogner.moho>, > Simon Wright <simon@pogner.demon.co.uk> wrote: > > is there a better way [of avoiding the warning] > > why not > > pragma Warnings (Off, Lock); Because I'm concerned that aggressive optimization (-O3) will eliminate the lock variable altogether. The last time this happened was Dummy : Foo := Some_Function_With_Side_Effects; and -O3 ended up without the side effects. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Simon Wright @ 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Robert Dewar @ 1999-04-12 0:00 UTC (permalink / raw) In article <x7vk8viqsla.fsf@pogner.moho>, Simon Wright <simon@pogner.demon.co.uk> wrote: > Because I'm concerned that aggressive optimization (-O3) > will eliminate the lock variable altogether. > > The last time this happened was > > Dummy : Foo := Some_Function_With_Side_Effects; > > and -O3 ended up without the side effects. Well that would have course have been a significant bug, and we have never seen any such bug in -O2 mode (-O3 is irrelevant here), nor had any such problem reported that I can remember. The backend may well remove the variable itself, but cannot remove the call. With regard to initialization and finalization, the ARG just agreed (unwisely if you ask me!) to allow a compiler to optimize away initialization and finalization for an otherwise unreferenced variable. GNAT does not take advantage of this, but it means that to be compeltely portable, you need to put in a dummy reference to the variable. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Robert Dewar @ 1999-04-12 0:00 ` Simon Wright 1999-04-14 0:00 ` Robert Dewar 1999-04-12 0:00 ` Jean-Pierre Rosen 1999-04-13 0:00 ` Tom Moran 2 siblings, 1 reply; 24+ messages in thread From: Simon Wright @ 1999-04-12 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-dejanews.com> writes: > In article <x7vk8viqsla.fsf@pogner.moho>, > Simon Wright <simon@pogner.demon.co.uk> wrote: > > Because I'm concerned that aggressive optimization (-O3) > > will eliminate the lock variable altogether. > > > > The last time this happened was > > > > Dummy : Foo := Some_Function_With_Side_Effects; > > > > and -O3 ended up without the side effects. > > Well that would have course have been a significant bug, > and we have never seen any such bug in -O2 mode (-O3 > is irrelevant here), nor had any such problem reported > that I can remember. The backend may well remove the > variable itself, but cannot remove the call. In what way irrelevant? Am I supposed not to use -O3? or do you just mean that there is no distinction here between 2 and 3 (I only have the 3.10 version of the secret manual here, it indicates that -O3 only adds automatic inlining). I certainly saw this with GNAT 3.11p, the compiler warned that the variable was unused, when I compiled -O3 there was a misbehaviour in my code explainable as above, change the code to achieve the side-effect via a procedure call in the body and the misbehaviour goes away. I can try to reconstitute the problem and report it (if it is indeed a bug to optimize away the initialization of an unused variable? it struck me at the time that it was much more my fault!) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Simon Wright @ 1999-04-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1999-04-14 0:00 UTC (permalink / raw) In article <x7vzp4dscsv.fsf@pogner.moho>, Simon Wright <simon@pogner.demon.co.uk> wrote: > I can try to reconstitute the problem and report it (if > it is indeed a bug to optimize away the initialization of > an unused variable? it struck me at the time that it was > much more my fault!) It is perfectly fine to optimize away the initialization, and indeed the variable itself. But what would possibly make you think (RM reference please) that it was OK to eliminate the call. Optimizations, except where specifically permitted by 11.6, must not affect the external behavior! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright @ 1999-04-12 0:00 ` Jean-Pierre Rosen 1999-04-12 0:00 ` Simon Wright ` (2 more replies) 1999-04-13 0:00 ` Tom Moran 2 siblings, 3 replies; 24+ messages in thread From: Jean-Pierre Rosen @ 1999-04-12 0:00 UTC (permalink / raw) Robert Dewar a �crit dans le message <7esrmv$k1n$1@nnrp1.dejanews.com>... >With regard to initialization and finalization, the ARG >just agreed (unwisely if you ask me!) to allow a compiler >to optimize away initialization and finalization for an >otherwise unreferenced variable. GNAT does not take >advantage of this, but it means that to be compeltely >portable, you need to put in a dummy reference to the >variable. Only for non-limited controlled types. If you don't use the variable, make the type limited. It makes no difference, and the AI ensures that Initialization/Finalization is NOT optimized away. --------------------------------------------------------- J-P. Rosen (Rosen.Adalog@wanadoo.fr) Visit Adalog's web site at http://perso.wanadoo.fr/adalog ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Jean-Pierre Rosen @ 1999-04-12 0:00 ` Simon Wright 1999-04-13 0:00 ` Robert Dewar 1999-04-13 0:00 ` Robert Dewar 2 siblings, 0 replies; 24+ messages in thread From: Simon Wright @ 1999-04-12 0:00 UTC (permalink / raw) "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes: > Only for non-limited controlled types. If you don't use the variable, > make the type limited. It makes no difference, and the AI ensures that > Initialization/Finalization is NOT optimized away. Strictly, I suppose, the AI only adds weight to a complaint to your compiler vendor when he's got it wrong .. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Jean-Pierre Rosen 1999-04-12 0:00 ` Simon Wright @ 1999-04-13 0:00 ` Robert Dewar 1999-04-13 0:00 ` Robert Dewar 2 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1999-04-13 0:00 UTC (permalink / raw) In article <7eta1t$pp0$2@wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > Only for non-limited controlled types. If you don't use > the variable, make the type limited. It makes no > difference, and the AI ensures that > Initialization/Finalization is NOT optimized away. I still consider this to be a FAR too extensive implementation dependency, it means that programs that work fine on one compiler malfunction in the most odd way on another, because locks are simply mysteriously missing. As I noted, GNAT has NO intention of taking advantage of this optimization freedom, which seems extremely marginal in any case. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Jean-Pierre Rosen 1999-04-12 0:00 ` Simon Wright 1999-04-13 0:00 ` Robert Dewar @ 1999-04-13 0:00 ` Robert Dewar 2 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1999-04-13 0:00 UTC (permalink / raw) In article <7eta1t$pp0$2@wanadoo.fr>, "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote: > Only for non-limited controlled types. If you don't use > the variable, make the type limited. It makes no > difference, and the AI ensures that > Initialization/Finalization is NOT optimized away. Note that a quite natural style is to declare such a variable with an initialization expression that does something, and that will lead you naturally to a non-limited type, which is the case that can cause you trouble, but perhaps not immediately if your compiler feels that it should NOT optimize this away. I hope at least that compilers that perform this unwise optimization will warn users that they are doing it. Warning: I have removed the Initialization/Finalization calls for the object "Critical_Lock_Do_Not_Remove". Or some such message .... -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright 1999-04-12 0:00 ` Jean-Pierre Rosen @ 1999-04-13 0:00 ` Tom Moran 1999-04-15 0:00 ` Robert Dewar 1999-04-20 0:00 ` Tom Moran 2 siblings, 2 replies; 24+ messages in thread From: Tom Moran @ 1999-04-13 0:00 UTC (permalink / raw) >With regard to initialization and finalization, the ARG >just agreed (unwisely if you ask me!) to allow a compiler >to optimize away initialization and finalization for an >otherwise unreferenced variable. It seems such a bad idea - what arguments led them to this decision? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-13 0:00 ` Tom Moran @ 1999-04-15 0:00 ` Robert Dewar 1999-04-15 0:00 ` Tom Moran 1999-04-20 0:00 ` Tom Moran 1 sibling, 1 reply; 24+ messages in thread From: Robert Dewar @ 1999-04-15 0:00 UTC (permalink / raw) In article <3713b417.22324981@news.pacbell.net>, > It seems such a bad idea - what arguments led them to > this decision? There are good arguments on both sides. See the AI (this is not secret information :-) -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-15 0:00 ` Robert Dewar @ 1999-04-15 0:00 ` Tom Moran 1999-04-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Tom Moran @ 1999-04-15 0:00 UTC (permalink / raw) > See the AI Which one. There are quite a few to search through. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-15 0:00 ` Tom Moran @ 1999-04-16 0:00 ` Robert Dewar 1999-04-16 0:00 ` Tom Moran 0 siblings, 1 reply; 24+ messages in thread From: Robert Dewar @ 1999-04-16 0:00 UTC (permalink / raw) In article <371658a7.19974365@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > > See the AI > Which one. There are quite a few to search through. I don't know, it is you who wants to read it, so I figure you get to do the search :-) :-) (but maybe Tuck or Bob or someone else can lay their hands on the number more easily ...) > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-16 0:00 ` Robert Dewar @ 1999-04-16 0:00 ` Tom Moran 1999-04-16 0:00 ` Tucker Taft 0 siblings, 1 reply; 24+ messages in thread From: Tom Moran @ 1999-04-16 0:00 UTC (permalink / raw) I found AI-00147, which as far as I can see gives no significant arguments *for* eliminating in the non-limited case, except "doing Initialization/Finalization is expensive". It seems to that either the programmer intended the object to be declared, even though he doesn't use it, or it was a mistake on his part and a warning should be generated (as for unused Integer, Boolean, and other non-controlled types). So possibly such a warning in the non-limited case would be reasonable, but simply assuming the programmer did not really intend to declare the controlled object, is hubris. Or is there another AI that I missed? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-16 0:00 ` Tom Moran @ 1999-04-16 0:00 ` Tucker Taft 1999-04-16 0:00 ` Tom Moran 1999-04-16 0:00 ` Tom Moran 0 siblings, 2 replies; 24+ messages in thread From: Tucker Taft @ 1999-04-16 0:00 UTC (permalink / raw) Tom Moran wrote: > > I found AI-00147, which as far as I can see gives no significant > arguments *for* eliminating in the non-limited case, except "doing > Initialization/Finalization is expensive". It seems to that either > the programmer intended the object to be declared, even though he > doesn't use it, or it was a mistake on his part and a warning should > be generated (as for unused Integer, Boolean, and other non-controlled > types). So possibly such a warning in the non-limited case would be > reasonable, but simply assuming the programmer did not really intend > to declare the controlled object, is hubris. > Or is there another AI that I missed? Here is a motivating example: X : My_Controlled_Type; begin ... X := Y; ... end; Presuming My_Controlled_Type has a user-defined Initialize, Finalize, and Adjust, the sequence of implicit calls currently required is: Initialize(X); ... Finalize(X) <copy Y to X> Adjust(X) ... Finalize(X) The goal is to eliminate the first Initialize/Finalize pair. Doing this requires some care, because if an exception is raised before the assignment of Y to X, you don't want X to be finalized if it has never been initialized. Perhaps one way to resolve the concern is to give the permission to remove an Initialize/Finalize pair only if there is an assignment (presumably with Adjust) to the object, essentially allowing the creation of the object to be deferred until the first assignment, thereby bypassing the need for any default initialization. -Tuck -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-16 0:00 ` Tucker Taft @ 1999-04-16 0:00 ` Tom Moran 1999-04-19 0:00 ` Tucker Taft 1999-04-16 0:00 ` Tom Moran 1 sibling, 1 reply; 24+ messages in thread From: Tom Moran @ 1999-04-16 0:00 UTC (permalink / raw) >permission >to remove an Initialize/Finalize pair only if there is an assignment Ah, so the complete removal of the (seemingly) unused control type declaration is a consequence of being able to optimize the case where it is in fact used (later)? > Initialize(X); > ... > Finalize(X) > <copy Y to X> What happens if the Initialize or Finalize of X, (which will be optimized away) modifies Y? Or is that illegal? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-16 0:00 ` Tom Moran @ 1999-04-19 0:00 ` Tucker Taft 0 siblings, 0 replies; 24+ messages in thread From: Tucker Taft @ 1999-04-19 0:00 UTC (permalink / raw) Tom Moran (tmoran@bix.com) wrote: : >permission : >to remove an Initialize/Finalize pair only if there is an assignment : Ah, so the complete removal of the (seemingly) unused control type : declaration is a consequence of being able to optimize the case where : it is in fact used (later)? : > Initialize(X); : > ... : > Finalize(X) : > <copy Y to X> : What happens if the Initialize or Finalize of X, (which will be : optimized away) modifies Y? Or is that illegal? It is certainly not "illegal," but if this rule is adopted, it would probably be unwise ;-). The point of rules like this is to allow controlled objects to be treated largely like "normal" variables w.r.t. dead load/store removal, value propagation, etc. The rule would be analogous to the rule about functions in declared-pure packages. They need not be called under certain circumstances, independent of whether they do or do not have "interesting" side-effects. It is the programmer's responsibility to create operations that are consistent with the possibility that they might be "optimized away." -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-16 0:00 ` Tucker Taft 1999-04-16 0:00 ` Tom Moran @ 1999-04-16 0:00 ` Tom Moran 1 sibling, 0 replies; 24+ messages in thread From: Tom Moran @ 1999-04-16 0:00 UTC (permalink / raw) What we really need is a way to speak of an 'extended object', eg, a linked list of objects or an attached set of peripheral devices, etc.. The only way now is to make controlled components and then have them do list walking or hardware setup/takedown, or whatever. The abstract "object" in those cases is something much larger than a single chunk of data. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-13 0:00 ` Tom Moran 1999-04-15 0:00 ` Robert Dewar @ 1999-04-20 0:00 ` Tom Moran 1999-04-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 24+ messages in thread From: Tom Moran @ 1999-04-20 0:00 UTC (permalink / raw) >>With regard to initialization and finalization, the ARG >>just agreed (unwisely if you ask me!) to allow a compiler >>to optimize away initialization and finalization for an >>otherwise unreferenced variable. >It seems such a bad idea - what arguments led them to this decision? Randy Brukardt was kind enough to educate me on some of the points here, including procedure Something(P : in integer) is Unused : integer := P/0; begin ... which can legally have Unused eliminated and thus the divide by zero eliminated. That certainly provides an analogous precedent for eliminating the controlled Initialize/Finalize. So with 'limited' still available when you really gotta have Initialize/Finalize, I guess it's not so unreasonable to eliminate the controlled object (in the non-limited) case after all. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-20 0:00 ` Tom Moran @ 1999-04-20 0:00 ` Robert Dewar 1999-04-20 0:00 ` Tom Moran 0 siblings, 1 reply; 24+ messages in thread From: Robert Dewar @ 1999-04-20 0:00 UTC (permalink / raw) In article <3718268c.48395643@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > Randy Brukardt was kind enough to educate me on some of > the points here, including > procedure Something(P : in integer) is > Unused : integer := P/0; > begin ... > which can legally have Unused eliminated and thus the > divide by zero eliminated. That certainly provides an > analogous precedent for eliminating the controlled > Initialize/Finalize. This is a bad analogy. Yes, I know that some of the ARG members used this to justify the position taken, but the reasoning is faulty. In the case of built-in language checks, the idea is to prevent the program from doing something bad. In other words a divide by zero is an error in your program, and if it happens you want to know about it. We decided early on in Ada 83 that it was OK to eliminate such exceptions if the situation leading to the error can be safely eliminated. There are three reasons here: 1) We really don't want the nice checking in Ada to damage code generation unnecessarily. Programmers want to know if a real error occurs, but they do not need to know EXACTLY where a constraint error is raised, or to know about a CE that in fact was not raised at all for good and sound reasons. 2) If we eliminate the divide in a case like this, we eliminate the error. So the idea of run time checks, to check for errors is not violated by this optimization. 3) A correct program does not raise exceptions like this anyway (if you use divide by zero as a normal case control structure, you should be drummed out of the Ada community!) This means that correct programs are not affected by these kinds of optimizations. Now the initialize/finalize case is TOTALLY different. None of the above considerations applies. In fact this is the thin end of a very dangerous wedge. Here for the first time we have well defined behavior from a program, which we know that existing programs sometimes use for good reasons, and we suddenly introduce a new rule which allows the optimizer to optionally change the behavior of the program in a fundamental way that is incompatible with what is in the RM. This is not what I call an optimization! Yes, there have been discussions of possible optimizations in the case of temporaries created by the compiler, but such temporaries are in some sense an artifact of the implementation anyway. Here we are talking about a declared variable, and it is 100% clear that the current RM requires the initialize and finalize call. Why the thin end of the wedge? Because next someone will say X : Integer := Function_With_Side_Effects; is allowed NOT to call the function if X is unused, and away we go down the slippery slope. A couple of further points here. GNAT will most certainly NOT take advantage of this optimization, it seems a bad idea. If you have no user defined initialization routine, and a finalization routine whose only purpose is to release storage, then you can use the GNAT pragma pragma Finalize_Storage_Only (subtype_NAME); which tells the compiler to omit the Finalize call if it is not needed, e.g. at the outer level, or all the time in a Java environment. Such pragmas that control the behavior of the compiler are legitimate, and I would have no objection to a pragma saying pragma Omit_Initialize_Finalize_For_Unused; but to allow this optimization without such a pragma is to me a language change justified only by the hope that an "optimization" will be significantly worth while (only a hope, no quantitative data of any kind is available!) Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-20 0:00 ` Robert Dewar @ 1999-04-20 0:00 ` Tom Moran 1999-04-21 0:00 ` Robert Dewar 0 siblings, 1 reply; 24+ messages in thread From: Tom Moran @ 1999-04-20 0:00 UTC (permalink / raw) >> procedure Something(P : in integer) is >> Unused : integer := P/0; >> begin ... >> which can legally have Unused eliminated and thus the >> divide by zero eliminated. That certainly provides an >> analogous precedent for eliminating the controlled >> Initialize/Finalize. >This is a bad analogy. How about type Back_Track_Type is array(integer range <>) of integer; function Big_Calculation(Distance:in integer; Time:in integer; ...) return Back_Track_Type is Speed : integer := Distance/Time; Where_it_was : Back_Track_Type(1 .. Time); begin -- various calculations, some of which assume that the speed is non-zero, but none of which actually mentions the variable "Speed" Granted, this would be poor programming, but the Distance/Time calculation would give a divide by zero at the start of Big_Calculation, while optimizing it away might result in erroneous calculations that wouldn't show up till much later, in some other place when it is surprisingly discovered that the back_track array returned from the function was in fact null. It seems to me that's a closer analogy in terms of the difference in program behavior. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Unreferenced lock variables 1999-04-20 0:00 ` Tom Moran @ 1999-04-21 0:00 ` Robert Dewar 0 siblings, 0 replies; 24+ messages in thread From: Robert Dewar @ 1999-04-21 0:00 UTC (permalink / raw) In article <371cadb6.1137490@news.pacbell.net>, tmoran@bix.com (Tom Moran) wrote: > It seems to me that's a > closer analogy in terms of the difference in program > behavior. I disagree strongly, but I have nothing further to add from my previous message, which covers this situation completely. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~1999-04-21 0:00 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-04-11 0:00 Unreferenced lock variables Simon Wright 1999-04-11 0:00 ` Tom Moran 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright 1999-04-12 0:00 ` Robert Dewar 1999-04-12 0:00 ` Simon Wright 1999-04-14 0:00 ` Robert Dewar 1999-04-12 0:00 ` Jean-Pierre Rosen 1999-04-12 0:00 ` Simon Wright 1999-04-13 0:00 ` Robert Dewar 1999-04-13 0:00 ` Robert Dewar 1999-04-13 0:00 ` Tom Moran 1999-04-15 0:00 ` Robert Dewar 1999-04-15 0:00 ` Tom Moran 1999-04-16 0:00 ` Robert Dewar 1999-04-16 0:00 ` Tom Moran 1999-04-16 0:00 ` Tucker Taft 1999-04-16 0:00 ` Tom Moran 1999-04-19 0:00 ` Tucker Taft 1999-04-16 0:00 ` Tom Moran 1999-04-20 0:00 ` Tom Moran 1999-04-20 0:00 ` Robert Dewar 1999-04-20 0:00 ` Tom Moran 1999-04-21 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox